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INTRODUCTION 


General 

The  purpose  of  this  guide  is  to  provide  guidelines  for  tho  preparation  of 
Proposed  Technical  Approaches  (PTA)  documents  and  an  explanation  of  the 
need  for  the  information  required  therein.  It  is  intended  for  use  by  all  who 
have  an  interest  in  tho  preparation  and  review  of  PTA's.  It  is  a  companion  to 
the  “Guide  for  the  Preparation  of  Technical  Development  Plans  (TDP)’’ 
(NAVMAT  P8010)  published  by  direction  of  the  Chief  of  Naval  Material 
(CNM).  It  is  analogous  to  the  TDP  guide  in  that  it  is  intended  as  a  gu.  ,<j 
rather  than  an  inflexible  set  of  rules.  However,  adherence  to  the  general  scope 
and  intent  of  the  suggestions  provided  herein  should  provide  responsive  and 
comiuUivutr'.'.i  documents  including  all  of  the  information  usually  required 
in  a  FrA.  Each  section  of  this  guide  is  organized  in  accordance  with  the 
instructions  for  PTA  preparation  described  in  OPNAVINST  3910.8  Series. 
A  check  list  is  found  at  the  end  of  each  section  which  emphasizes  the  major 
points  which  should  be  covered  in  the  corresponding  PTA  section. 

Attention  is  invited  to  the  Handbook  for  the  Preparation  of  Proposed 
Technical  Approaches  (PTA)  (NAVMAT  P3910A  SUP-1)  which  contains 
more  detailed  guidance  for  individuals  engaged  in  PTA  preparation. 

Description  and  Purpose  of  PTA 

A  PTA  document  presents  alternative  approaches  for  a  system  or  com¬ 
ponent  concept  stated  or  implied  in  a  General  Operational  Requirement 
(GOR).  PTA’s  are  prepared  for  the  Chief  of  Naval  Operations  (CNO)  by 
the  Naval  Material  Support  Establishment  (NMSE)  or  other  offices  or  bu¬ 
reaus,  either  as  a  required  response  to  a  Tentative  Specific  Operational  Re¬ 
quirement.  (TSOR)  or  voluntarily  in  response  to  a  GOR.  Both  the  GOR  and 
the  TSOR  are  promulgated  by  CNO.  An  explanation  of  tho  purposs  and 
relationship  of  the  various  Research,  Development,  Test,  and  Evaluation 
(RDT&E)  requirements  and  reporting  documents  is  contained  in 
OPNAVINST  3900.8  Series.  Figure  1  depicts  tho  sequence  of  evolutionary 
steps  required  in  systems  development  and  the  place  that  the  PTA  nnd  other 
official  documents  occupy  in  the  process.  Voluntarily  submitted  PTA’s  may 
be  submitted  at  any  time,  while  those  responsive  to  a  TSOR  arc  due  within 
90  days  of  the  date  of  the  TSOR.  However,  tho  CNO  is  not  hound  in  any  way 
to  respond  to  a  PTA  with  an  ADO  or  SOR, 

The  Marine  Corps  independently  develops  requirements  for  material 
which  is  used  primarily  for  its  own  missons,  Although  the  greater  number  of 
PTA’s,  by  far,  will  he  generated  for  missions  under  the  purview  of  CNO,  the 
contents  of  this  guide  are  fully  applicable  to  PTA’s  addressing  Marine  Corps 
requirements. 


v 


■IIJI  .»W|I»|i,;ii.ii|i,|iU,||II||1 


A  PTA  serves  (our  needs : 

ft.  It  provides  ft  foraftl  means  by  which  new  technology  ie  introduced  into 
naval  wftrfftre  systems. 

b.  It  presents  certain  technical  and  financial  information  to  the  CNO 
on  whioh  to  base  a  decision  to  commence  n  development  program; 

therefore; 

o.  It  provides  technical  and  financial  information  necessary  for  prepara' 
tion  of  a  Speoifio  Operational  Requirement  (SOR),  or  Advanced  De¬ 
velopment  Objective  (ADO)  as  appropriate. 

d.  It  provides  the  initial  estimates  of  development  and  production  costs 
in  order  to  determine  whether  a  formal  Contract  Definition  will  be 
required.  In  the  event  the  proposed  development  appears  to  meet  the 
criteria  for  Contract  Definition,  the  PTA  will  be  a  necessary  step  in 
meeting  the  prerequisites  for  Contract  Definition. 

A  PTA  normally  contains  a  description  of  the  problem  to  be  solved  with 
reference  to  the  pertinent  GOR  or  TSOR,  and  includes  a  functional  description 
of  each  alternate  system  or  component  concept  as  well  as  a  diagram  of  typical 
operational  usage  and  a  functional  flow  diagram  of  included  sub-systems  and 
associated  systems.  It  discusses  operational  effectiveness  in  terms  of  perform- 
ance,  reliability,  operability,  and  maintainability.  It  contains  trade-off  analyses 
of  the  various  alternative  approaches  in  terms  of  effectiveness,  development 
time  and  cost.  It  includes  a  recommendation  as  to  the  RDTAE  Category  under 
which  the  development  should  be  pursued  as  well  as  to  the  preferred  technical 
approach  of  the  several  presented.  In  addition,  for  management  planning, 
the  PTA  contains  a  preliminary  schedule  of  major  milestones  of  development 
shown  in  time  sequence  and  an  estimate  of  funds  needed  each  year.  Personnel 
implications  of  proposed  systems  are  addressed  as  well. 

Importance  of  PTA 

Since  the  PTA  is  the  initial  Research  and  Development  dooument  which 
forecasts  procurement  workload  in  RAD,  it  is  of  considerable  concern  to  pro¬ 
curement  planners.  In  all  probability,  the  personnel  implications  of  a  proposed 
system  will  be  addressed  for  the  first  time  in  the  PTA  proposing  the  system. 
A  PTA  is  often  used  as  a  selling  document  for  a  development  that  the  origi¬ 
nating  organization  considers  worthwhile.  As  such,  it  is  in  competition  with 
many  other  demands  for  development  money.  In  general,  the  better  the  PTA 
the  more  it  will  cost  to  produce.  However,  the  relative  expensiveness  of  the 
PTA  must  be  considered  in  relation  to  the  desire  to  “sell”  the  development 
addressed. 


Submittal  of  PTA’s 

The  PTA  documents  are  forwarded  to  CNO  via  CNM.  Organizations 
within  the  NMSE  are  encouraged  to  submit  PTA’s  voluntarily  in  response 
to  a  GOR.  Naturally,  all  such  PTA’s  do  not  lead  to  issuance  of  an  SOR  or 
TSOR,  at  least  on  their  initial  submission.  As  more  is  learned,  PTA’s  may 
be  updated  and  resubmitted.  To  expedite  the  review  of  resubmitted  PTA’s, 
the  nature  of  the  change  should  be  indicated  in  the  forwarding  letter  and  the 
document  itself.  This  should  be  done  in  the  document  by  indicating  a  revision 
date  on  the  cover  sheet  and  inclusion  of  an  “Index  of  Effective  Pages”  similar 
to  that  used  in  a  TDP. 

Experience  to  date  with  processing  documents  including  PTA’s  has  dem¬ 
onstrated  that  CNM  approval  can  be  expedited  by  informal  consultation 
between  the  Principal  Development  Agency  (PDA)  and  NAVMAT  during 
the  draft  copy  stage. 

“Advance  Copies” 

As  a  general  rule,  “advance  copies”  should  not  be  circulated  outside  the 
NMSE  and  designated  support  activities  before  review  and  approval  by  CNM. 
This  is  not  intended  to  interfere  with  the  free  interchange  of  information 
between  the  Material  Bureaus  and  OPN  AV.  However,  embarrassing  situations 
and  unnecessary  added  workload  for  CNO  can  result  from  free  circulation  of 
documents  which  may  not  be  subsequently  approved  by  CNM.  When  spe¬ 
cifically  requested  by  higher  authority,  a  draft  copy  of  a  PTA  may  be  sub¬ 
mitted  as  back-up  data.  It  should  be  identified  as  a  draft  copy  in  all  corre¬ 
spondence  and  use  of  the  document,  and  should  display  prominently  the 
following  information  on  the  cover  and  title  page,  “DRAFT  COPY,  HAS 
NOT  BEEN  APPROVED  BY  CNM”. 

Variations  in  PTA’s 

The  scope  of  a  PTA,  and  to  some  extent  its  tone,  will  vary  according  to 
the  type  of  requirement  document  to  which  the  PTA  replies,  and  also  to  the 
type  of  requirement  document  that  the  PTA  is  expected  t>  elicit  from  the 
Chief  of  Naval  Operations  (CNO) .  Programs  of  great  diversity  are  sponsored 
by  the  NMf?E  resulting  in  a  rather  wide  variation  in  PTA  documents.  The 
maturity  of  «  development  influences  tire  nature  of  a  PTA  addressing  it.  The 
PTA  for  a  System  concept  will  ordinarily  be  different  in  scope  from  that  of 
a  PTA  for  a  component  or  “building  block”  which  may  later  be  combined  with 
other  “building  blocks”  to  produce  a  system.  The  variations  possible  are  dis¬ 
cussed  in  the  sections  which  follow. 


All  PTA.  documents  apeak  to  a  “Bess  Line”  system  or  device,  i.e.,  the 
system  concept  or  device  which  serves  as  the  model  against  which  the  alterna¬ 
tives  are  to  be  compared  and  trade-offs  made.  In  a  PTA  responding  to  a 
TSOR,  the  “Base  Lino"  system  or  device  is  described  in  the  TSOR  in  terms  of 
operational  concept,  threat  to  be  countered  or  noncombatant  application,  de¬ 
sired  performance  characteristics,  compatibility  requirements  and  such  other 
attributes  as  may  be  deemed  important.  The  unsolicited  PTA,  on  the  other 
hand,  must  postulate  this  “Base  Line”  system  concept  or  device.  It  usually 
follows  then  the .  the  “Base  Line”  system  concept  or  device  presented  in  such 
a  PTA  is  also  the  one  which  the  preparing  activity  believes  to  have  most  merit. 
In  either  case,  however,  the  basic  requirement  for  the  presentation  in  the  PTA 
of  alternative  approaches  must  be  met. 

Establishing  User-Producer  Dialogue 

Complex  systems  involve  so  many  individuals  and  offices  on  both  the  user 
aftd  producer  sides  of  the  house  that  serious  “language  gaps”  can  develop. 
Therefore,  the  user-producer  dialogue  should  be  started  as  soon  as  possible 
in  a  development  so  that  clear  channels  of  communication  can  be  established. 

In  particular,  increased  emphasis  on  reliability,  operability,  maintain¬ 
ability,  etc.,  has  made  it  absolutely  imperative  that  human  factors  experts, 
both  in  the  Material  Bureaus  and  in  the  Bureau  of  Naval  Personnel,  be  con¬ 
sulted  during  the  formulative  period  of  all  developments. 

Updating  of  Guide 

It  is  intended  that  this  guide  will  be  periodically  revised  and  updated  to 
reflect  the  varied  needs  of  groups  within  the  NMSE. 

This  publication  has  been  reviewed  and  approved  in  compliance  with 

SECNAVINST  5600.16. 


Deputy  Chief  of  Naval  Material  for 
Development/Chief  of  Naval  Development 


PROPOSED  TECHNICAL  APPROACHES  FORMAT 


GmuttA 

Enclosure  (2)  of  (HPNAVINST  8910.8  Series  preser  w  a  suggested  format 
for  presentation  of  the  information  required  for  the  PTA.  It  is  generally 
similar  to  that  for  a  TUP  but  is  somewhat  abbreviated  and  rearranged  to 
bettor  suit  the  different  character  of  the  PTA  document.  The  TDP  treats  a 
system  which  has  been  singled  out  for  development,  while  the  Proposed  Tech¬ 
nics!  Approaches  document,  as  its  name  implies,  must  compare  a  number  of 
approaches  and  show  trade -offs  in  such  parameters  as  effectiveness,  cost  and 
development  time.  Other  formats  may  be  used  provided  that  all  of  the  re¬ 
quired  information  »  presented  clearly  and  there  is  a  good  reason  for  such 
deviation.  Improved  “brochuremanship”  is  not  considered  to  be  a  good  reason. 
In  cases  where  a  gnat  -deal  of  development  has  been  done,  the  PTA  format 
may  adhere  to  the  TIM*  format  as  this  will  facilitate  later  transition  from 
PTA  to  TDP. 

Cover  Sheet  wed  Tab!*  of  Contents 

A  sample  cover  sheet  containing  the  required  information  is  shown  in 
Figure  2.  It  is  highly  desirable  that  all  covers  be  uniform  so  that  each  PTA 
can  be  quickly  and  accurately  identified.  Figure  3  shows  a  sample  table  of 
contents  for  the  suggested  format. 

Generation  of  Information  for  PTA 

Figure  4  is  a  flow  ©hart  showing  the  sequence  of  generation  of  the  infor¬ 
mation  required  in  the  finished  PTA. 

Format  Sensathrlty  to  Contents 

As  pointed  out  in  the  Introduction,  the  scope  and  time  of  various  PTA 
documents  will  differ.  However,  the  basic  informational  content  and  the 
format,  should  be  essentially  the  same  whether  it  is  solicited  or  unsolicited, 
whether  it  deals  with  &  complete  system  or  a  subsystem  or  lesser  element,  and 
regardless  of  the  type  of  response  ( ADO,  SOR  or  other  directive)  Bought 
from  CNO.  Differences  in  the  treatment  to  accommodate  these  several  cir¬ 
cumstances  should  be  in  the  nature  of  “slants”  brought  about  by  minor 
differences  in  the  presentation  of  the  technical  material. 


CLASSIFICATION 


PTA  (Number)  (See  Note  1) 

PROPOSED  TECHNICAL  APPROACHES 
for 

( Program  N ame )  ( See  Note  2) 

Supports  GOR/TSOR  Number _  (See  Note  3) 

Project  No. _ 


Submitted  by 


(Name  of  Bureau,  Office,  etc.) 
Department  of  the  Navy 
Washington,  D.C.,  20360 


Original  Issue _ _ 

Last  Previous  Revision _ 

(Omit  if  original  or  first  revision) 

Current  Revision _ 

(Omit  if  original) 

Copy  No. _ of _ Copies  (For  Secret  and  Top  Secret) 


CLASSIFICATION 

Note  1 :  Sea  OPNAYINST  3910.8  Series  for  PTA  Numbering  System.  Unsolicited  PTAs 
will  provide  all  elements  of  the  designation  except  the  second  two  numbers  which 
are  unique  to  the  individual  requirement  under  a  GOR.  Bureau  numbering  sys¬ 
tem*  may  also  be  shown  until  an  assignment  is  made  by  CNO. 

Note  2:  Identify  system  by  title  of  T30R  If  issued.  When  Acronyms  are  used  in  the  title 
the  words  from  which  they  are  derived  will  appear  In  imrentheals  after  or  uhder 
the  word  as  appropriate. 

Note  3 :  Use  only  If  Project  No.  is  different  from  PTA  No. 


Figure  2.  Sample  PTA  Cover  Sheet. 
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Philosophy  oa  Content 

It  is  sometimes  argued  that  a  PTA  document,  and  particularly  the  un¬ 
solicited,  subeystem-or-lesser-component  type,  need  not  and  sometimes  cannot 
respond  in  any  way  to  the  area  of  performance  or  other  general  design  attri¬ 
butes  and  operational  considerations  such  as  reliability,  maintainability,  opera¬ 
bility,  compatibility,  manpower  and  training  considerations,  etc.  Although  it 
is  conceded  that  there  are  instances  wherein  a  discussion  on  some  of  these 
topics  would  be  pointless,  this  should  be  the  exception  rather  than  the  rule. 
It  must  be  remembered  that  a  PTA  speaks  only  to  approaches  and  not  designs, 
and  that  whereas  the  worth  of  these  approaches  cannot  be  measured  quanti¬ 
tatively  and  in  some  instances  even  predicted,  a  qualitative  assessment  of  their 
potential  in  these  areas  must  be  presented  if  the  potential  user,  ONO,  or  other 
reviewing  authorities  are  to  be  in  a  position  to  rule  in  favor  of  undertaking 
the  project.  A  simple  demonstration  or  postulation  of  technical  feasibility 
alone  is  totally  inadequate  to  support  any  decision.  The  fact  that  something 
can  be  achieved  in  a  laboratory  does  not  support  a  decision  to  proceed  further 
if  there  is  no  basis  for  believing  that  the  attributes  against  which  effectiveness, 
and  hence  worth,  of  a  device  is  to  be  measured,  are  not  also  possible  of  achieve¬ 
ment  to  an  acceptable  level.  Discussion  on  these  topics,  end  good,  experienced, 
engineering  estimates  of  the  potential  inherent  in  the  “Base  Line”  and  alterna¬ 
tive  approaches,  is  therefore  required. 
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SECTION  1 


Foreword 

1.0  General 

This  section  is  one  of  the  most  important  in  the  entire  document  as  it 
sets  the  framework  and  indicates  the  need  for  the  development.  It  should, 
therefore,  be  most  carefully  done.  It  must  cover  the  required  information 
thoroughly  but  briefly,  making  reference  to  the  following  sections  for  detailB. 

1.1  Content 

Tho  Foreword  should  disclose  the  nature  and  extent  of  the  operational 
problem  to  be  solved,  and  provide  such  background  information  as  might  be 
available  and  appropriate  to  assist  in  developing  and  evaluating  approaches 
for  its  solution.  For  the  PTA  solicited  by  means  of  a  TSOR,  most  of  this 
information  can  be  provided  by  the  simple  expedient  of  including  and  ex* 
tracting  the  TSOR  document  itself.  For  the  unsolicted  PTA,  some  of  this 
information  may  be  extracted  from  the  GOR,  but  usually  some  must  also  be 
generated  and  provided  by  the  preparer  in  sufficient  detail  to  establish  the 
qualitative/quantitative  performance  and  compability  requirements,  capa¬ 
bilities  and  attributes  of  the  “Base  Line”  system  or  device. 

This  section  should  discuss  the  nature,  extent  and  status  of  the  research 
and  exploratory  development  programs  supporting  the  program.  This  may 
be  in  the  form  of  a  historical  bripf  covering  the  evolution  of  the  program.  It 
should  discuss,  in  appropriate  detail,  any  and  all  known  foreign  and  domestic 
programs,  projects,  tasks,  etc.  which  directly  or  indirectly  support  or  other¬ 
wise  relate  to  the  project  under  discussion,  and  include  a  statement  as  to  which 
of  these  can  be  used  in  this  development.  Any  major  problem  areas,  as  well  as 
proposed  or  existing  programs  for  their  solution,  should  be  mentioned  here 
with  reference  to  details  given  in  later  sections. 

1.2  Considerations  Determining  Content 

It  must  be  constantly  kept  in  mind  in  this  section  and  those  that  follow, 
what  response  is  expected  from  CNO.  The  informational  content  of  the  PTA 
must  conform  to  this.  The  required  contenis  of  the  various  requirements 
documents  are  included  in  the  following  documents:  General  Operational 
Requirement  (GOR),  OPNAVINST  3910.0  Series;  Specific  Operational  Re¬ 
quirement  and  Tentative  Specific  Operational  Requirement  (SOR  and  TSOR), 
OPNAVINST  3910.C  Series;  and  Advanced  Development  Objective  (ADO), 
OPNAVINST  3910.7  Series. 


for  Development 

In  order  to  emphasize  the  extent  of  the  need  for  the  proposed  develop¬ 
ment,  the  mein  requirements  as  posed  by  the  threat  (or  defioienoy)  should  be 
listed  in  a  table  oppoeite  the  capabilities  of  existing  and  planned  systems  (or 
components) .  An  analysis  of  the  most  significant  discrepancies  should  be 
made.  In  many  cases  the  systems  presently  in  the  fleet  will  appear  very 
deficient  It  should  be  remembered  that  many  of  these  were  designed  to  meet 
a  lower  order  threat.  Therefore,  It  is  best  to  quantify  suoh  deficiencies  and 
although  they  should  not  be  minimized,  at  the  same  time,  it  is  more  prudent 
not  to  uhneoessarily  criticize  the  present  systems. 


Foreword  Check  List 


1.  Statement  of  the  operational  or  technical  problem  to  be  solved. 

2.  Contains  statement  of  whether  the  PTA  is  solicited  or  unsolicited. 
8.  For  solicited  PTA : 

a.  Requirement  documents  answering  to 

b.  Summary  of  requirements 

4.  For  unsolicited  PTA : 

a.  GOR  answering  to 

b.  System  or  component  development 

c.  Performance  required 

d.  Compatibility  required 

5.  Background  for  development 

a.  Foreign  and  domestic  programs 

b.  Studies 

c.  Exploratory  development 


SECTION  2 


Description 


2.0  Objective  and  Content 

The  objective  in  this  section  is  to  tell  briefly  exactly  what  is  proposed  to 
be  developed.  For  each  alternative  approach  considered,  there  should  be  a 
brief  but  concise  presentation  of  how  it  functions  operationally  and  what  its 
capability  and  limitations  are  seen  to  be.  The  temptation  to  justify  or  push 
any  system  approach  should  be  avoided  in  this  section,  although  it  may  be 
desirable  to  designate  a  “Base  Line”  system  (or  device)  against  which  to 
compare  other  alternative  approaches.  To  clarify  the  explanations,  reference 
may  be  made  to  the  Operational  Diagram  and  Block  Diagram  which  usually 
follow.  This  should  be  a  fairly  short  section  since  detailed  performance  and 
compatibility  considerations  will  be  covered  in  later  sections.  The  most  concise 
way  of  depicting  this  and  the  method  which  should  be  used,  is  a  table  com¬ 
paring  the  major  requirements  posed  by  the  operational  threat  listed  opposite 
to  the  characteristics  and  capabilities  of  the  proposed  solutions. 

2.1  Considerations  for  Component  Development 

For  the  “Building  Block”  type  of  development,  there  should  be  a  detailed 
discussion  of  technical  problems  posed  by  the  several  associated  operational 
problems,  the  details  of  which  may  be  discussed  in  a  more  general  way  than 
for  systems  designed  for  specific  operational  use.  This  applies  only  to  the 
unsolicited  PTA  involving  subsystem  or  lesser  component  candidates  fcr 
advanced  development  status.  It  provides  insight  into  the  main  and  other 
attractive  operational  system  applications  foreseen  for  the  device.  The  solicited 
type  PTA,  on  the  other  hand,  replies  to  a  specific  operational  problem  and  will 
normally  be  more  precise  and  narrow  in  scope. 


Description  Check  List 


1.  Nature  of  development. 

2.  Operational  function  of  “Base  Line'’  system  and  each  alternative  system. 

a.  Capabilities 

b.  Limitations 

3.  For  component  development  (“Building  Block”)  unsolicited  PTA. 
a.  Technical  limitations  posed  by  operational  problems. 


SECTION  3 


Operational  Diagram 

The  Operational  Diagram  should  be  a  rather  simple  drawing  showing 
the  main  elements  of  the  system  and  associated  systems  being  used  in  an  opera¬ 
tional  environment.  It  should  be  carefully  conceived  and  clearly  and  artis¬ 
tically  rendered  to  quickly  orient  the  reader  to  the  usefulness  of  the  proposed 
system. 

The  Operational  Diagram  should  be  labeled  using  the  same  terminology 
used  in  the  Operational  Brief  and  while  it  may  be  explained  in  the  Opera¬ 
tional  Brief,  it  should  be  reasonably  self-explanatory. 


u 

Operational  Diifna  Check  List 

1.  Operational  environment  clearly  depicted. 

2.  Most  usual  use  of  development  shown. 

S.  Enough  information  shown  to  make  situation  immediately  apparent 
4.  Pictorial  quality  good. 
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SECTION  4 


Block  Diagram 

4.0  Purpose 

The  Block  Diagram  provides  a  graphic  representation  of  the  essential 
“Building  Blocks”,  subsystems,  equipments,  components,  and  personnel  which 
constitute  the  system  (or  device)  to  be  developed  showing  their  functional 
relationship,  one  with  another  as  well  as  with  other  associated  systems  upon 
which  the  system  is  dependent  for  inputs,  or  which  in  turn  are  dependent  upon 
the  system  for  inputs.  This  diagram  supplements  the  functional  description 
given  in  Section  2,  Operational  Brief.  Details  of  interactions  with  associated 
systems  is  covered  in  Section  7,  Compatibility. 

4.1  Applicable  Instructions 

The  Block  Diagram  instructions  and  examples  given  in  the  TDP  instruc¬ 
tion,  OPNAV  3910.4  Series,  and  the  TDP  Guide  are  equally  applicable  for 
the  PTA.  Section  7,  Block  Diagram,  of  the  TDP  Guide  is  reproduced  as 
Appendix  B  of  this  guide. 

M  Problems  with  Previous  PTAs 

Observation  of  a  number  of  such  diagrams,  however,  has  indicated  that 
this  is  perhaps  the  least  understood  feature  of  either  PTA  or  TDP.  One  of 
the  main  faults  has  been  an  attempt  to  show  too  much  on  one  diagram,  result¬ 
ing  in  some  confusion.  More  than  one  diagram  can  be  used  when  necessary. 
Only  the  main  interactions  of  sub-systems  and  associated  systems  should  be 
shown.  A  great  many  lines  running  in  all  directions  is  very  confusing.  Sub¬ 
systems  which  normally  are  combined  into  a  functional  unit  should  be  so 
grouped  in  the  diagram(s). 
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Block  Diagram  Chock  List 

(See  “TDP  Check  List,  Section  7,  Block  Diagram”  reproduced  in  Appendix  B) 

1.  Representative  flow  diagram  of  interaction  of  major  parts. 

2.  Direction  of  actions  and  interaction  of  major  parts. 

8.  Major  subsystems  only  in  each  diagram. 

4.  Only  major  actions  and  interactions  shown  on  each  diagram. 

5.  Can  each  diagram  be  rather  quickly  understood! 

9.  Are  interactions  in  sub-system  shown  in  auxiliary  diagrams! 

7.  Are  human  functions  in  the  system  clearly  shown! 


( 


1 

V 
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SECTION  5 


Cost,  Time,  and  Performance  Envelopes 


5.0  General 

This  section  is  the  very  heart  of  the  PTA  document.  Acceptance  of  a 
proposed  development  is  largely  determined  by  its  cost,  timeliness  and  effective¬ 
ness  against  an  anticipated  threat  when  compared  to  competing  system 
concepts  or  devices.  Novel  and  improved  approaches  cannot  be  justified  for 
development  unless  they  show  a  considerable  increase  in  cost-effectiveness 
over  present  systems. 

5.1  Need  for  Alternate  Approaches 

Tho  reason  for  the  present  emphasis  on  approaches  is  to  be  round  in  the 
customary  relationship  of  user  and  producer.  The  user  (CNO)  s  more  likely 
to  be  satisfied  with  the  product  when  he  can  choose  from  among  several 
alternatives  supplied  by  the  producer  (NMSE).  CNO  must  have  and  use  this 
prerogative.  He  is  the  expert  on  operational  needs,  not  CNM  or  tire  material 
bureaus  in  the  NMSE.  The  NMSE  must  provide  enough  material  to  allow 
CNO  to  choose  an  adequate  technical  approach  to  meet  each  operational 
requirement. 

There  are  several  benefits  to  be  gained  from  presentation  of  a  number 
of  technical  approaches  to  the  solution  of  an  operational  problem.  One  is  the 
increased  flexibility  allowed  in  making  the  final  choice.  Another  is  that  tho 
Material  Bureaus  by  their  very  nature  may  see  problems  in  a  narrower  focus 
than  does  CNO-  The  Bureaus  may  see  as  the  best  choice  that  system  which 
is  most  refined  technically  provided  its  cost  is  within  reason.  However,  the 
final  choice  must  be  made  on  the  basis  of  many  factors;  technical,  fiscal, 
political  diplomatic  climate,  personnel  ceilings,  etc.  In  the  give  and  take  of 
budget  apportioning  process,  it  could  happen  that  a  very  worthwhile  but 
relatively  expensive  system  would  not  be  chosen  for  development,  whereas, 
a  less  costly  but  only  slightly  inferior  system  could  be  developed  to  meet 
the  same  requirement  resulting  in  an  increase  in  the  overall  effectiveness 
of  our  forces. 

5.2  Basis  for  Cost  Estimates 

Cost  estimates  must  be  made  for  life  cif  the  program  including  RDT&E, 
production,  delivery,  installation,  operation  and  support.  Also  included  will  be 
costs  for  personnel  research,  training  equipment,  and  personnel  training  costs 
for  operator  and  maintenance  personnel. 


5-1 


5A  Possible  Trade-offs 

Although  the  claim  is  sometimes  made  that  there  is  only  one  way  that 
certain  requirements  can  be  met,  this  view  may  be  based  on  a  lack  of  effort 
or  a  lack  of  imagination.  Even  assuming  that  one  can  find  a  requirement 
for  which  only  one  unique  approaoh  is  apparent,  some  trade-offs  should  be 
possible.  For  example,  a  given  system  or  equipment  may  be  designed  to  do 
a  given  job  at  different  levels  of  performance  or  reliability  {and  cost).  In 
general,  the  shorter  the  development  time  allowed,  the  higher  the  development 
cost.  Also,  the  military  worth  usnally  varies  somewhat  with  the  introduction 
date.  It  should  be  abundantly  clear  that  it  is  impossible  to  design  anything 
of  real  value  without  consideration  of  effectiveness,  cost  and  time.  In  the 
past,  many  of  the  trade-offs  and  optimization  of  design  factors  have  been 
done  more  or  less  subconsciously  by  the  designer  with  the  various  factors 
weighted  by  his  own  experience.  What  is  now  required  is  that,  the  design 
factors,  cost  factors,  development  time,  and  effectiveness  based  on  performance 
and  military  environment  may  be  identified  and  quantified,  that  meaning¬ 
ful!  trade-offs  be  made,  and  that  the  rationale  for  optimization  be  shown. 

5.4  Sources  of  Date 

The  PTA  instruction  is  very  lenient  in  allowing  almost  any  reasonable 
source  of  data  down  to  and  including  conjecture.  An  educated  guess  is  con¬ 
sidered  better  than  no  information  at  all.  It  stipulate®,  however,  that  the 
source  of  all  data  be  stated.  All  assumptions  made  should  be  clearly  defined. 
Often,  it  is  possible  early  in  a  development  to  obtain  meaningful  performance 
ratios  between  systems  when  it  is  actually  impossible  to  obtain  the  exact 
magnitude  of  performance  of  any  one  system.  Therefore,  a  plea  that  any 
development  is  in  too  early  a  state  .to  provide  trade-offs  can  hardly  be  justified. 
In  addition  to  the  sources  of  .background  information  referred  to  in  paragraph 
1.1,  many  other  sources  of  data  are  available  including  Navy  laboratories, 
other  NMSE  organizations,  paid  contractor  studies,  and  unsolicited  contractor 
proposals,  other  services  and  foreign  developments.  The  Bureau  of  Naval 
Personnel  and  the  Navy  Training  Devices  Center  can  provide  valuable  inputs 
on  human  problems.  Some  information  may  be  available  from  the  Department, 
of  Defense  Scientific  and  Technical  Information  Program  (ST1NFO).1 


*  See  DODIN8T  5100.S0,  5129.43  and  5100.38. 


5.5  Contents  of  Section 

This  section  should  discuss  subsystem,  equipment  and  component  technical 
approaches  considered  in  terms  of  the  parameters  (cost,  time,  performance 
and  other  attributes  including  size  and  weight )  which  establish  their  indi¬ 
vidual  merit,  ns  well  as  their  potential  contribution  to  the  effectiveness  (or 
lack  thereof)  of  both  the  “Base  Line"  and  alternative  systems  or  device. 
Responsiveness  to,  but  not  necessarily  agreement  with,  the  TSOR  expressed 
requirement  in  the  “Base  Line”  system  or  device  is  mandatory.  If,  for  any 
reason,  none  of  the  subsystem,  equipment,  or  component  technical  approaches 
presented  are  able  to  provide  any  of  the  qualitatively  and  quantitatively 
expressed  characteristics  in  the  TSOlt,  this  fact  should  be  noted  and  the 
departure  explained.  It  should  provide  a  comprehensive  development  and 
funding  schedule  by  fiscal  years  for  each  subsystem,  equipment  or  component 
shown  in  the  Block  Diagram  of  the  “Base  Lino”  system,  as  well  as  all  sup¬ 
porting  effort  that  would  be  require  l  in  the  management  of  the  project. 
Differences  in  the  time  and  cost  estimates  for  alternative  systems  or  devices 
may  bo  shown  in  separate  diagrams,  or  as  addenda  or  modifications  to  tiro 
diagram  of  the  “Base  Line”  system. 

Since  time  and  cost  considerations  figure  largely  in  the  decision  making 
processes  attending  the  entry  of  a  new  development  project  into  the  Five 
Year  Force  Structure  and  Financial  Program  (FYFS&FP),  it  is  essential 
that  these  factors  be  realistically  assessed  and  that  no  elements  of  co8t  be 
overlooked.  Although  the  estimates  presented  at  this  time  are  subject  to 
change  when  and  if  ADOs  or  SORs  are  issued  for  the  preparation  of  TDPs, 
they  must  not  be  optimistically  represented  in  order  to  “sell”  the  project. 

It  is  imperative  that  the  various  comparisons  and  trade-offs  be  clearly 
displayed  in  such  a  way  that  differences  in  design  parame:  configuration, 

physical  size,  weight,  performance,  cost,  effectiveness,  development  time,  etc., 
can  be  easily  and  quickly  compared.  Tables,  line  charts  and  graphs,  as  well 
as  pictorial  size  comparisons  and  other  visual  displays,  should  be  used  where 
appropriate.  Although  detailed  explanation  of  the  figures  should  be  found 
in  tho  text,  they  should  in  general  be  self-explanatory. 

5.6  Other  Considerations 

There  are  a  number  of  other  considerations  which  affect  tho  overall 
operational  effectiveness  or  overall  desirability  of  a  system  or  development. 
These  considerations  include  the  degree  of  risk,  logistics,  compatibility, 
countermeasures,  environmental,  reliability,  vulnerability,  maintainability, 
operability,  test  and  evaluation,  training  and  other  manpower  considerations. 
These  are  covered  in  the  four  sections  of  this  guide  that  follow.  Simplicity 
is  an  important  virtue  which  must  be  considered  in  nil  future  developments. 


Cost,  Time,  and  Performance  Envelopes  Check  List 

1.  Coat*  versus  development  time  of  “Base  Line”  and  alternative  systems. 

2.  Cost1  versus  performance  of  “Base  Line”  and  alternative  systems. 

8.  Performance  of  “Base  Line"  alternative  systems  versus  performance  of 
programmed  systems. 

4.  Cost1  effectiveness  comparison  of  “Base  Line,”  alternative,  and  pro¬ 
grammed  systems  (either  quantitative  or  qualitative,  whichever  is  most 
appropriate  and/or  possible). 

5.  Selection  factors  used  in  designation  of  threat  and  other  military  envi¬ 
ronment  conditions. 

6.  Sensitiveness  of  performance  and  effectiveness  to  change  in  threat. 

7.  Rationale  for  selection  preferred  system.  Has  consideration  been  given 
to  simplicity,  degree  of  risk,  logistics,  compatibility,  environmental 
factors,  reliability,  vulnerability,  maintainability,  operability,  test  and 
evaluation,  training  and  other  manpower  factors? 

8.  Basis  for  data  used  in  analyses. 

9.  Responsiveness  to  requirements  documents. 

19.  Development  and  funding  schedule  by  fiscal  years  for  all  major  parts. 

11.  Comparisons  of  physical  characteristics  of  “Base  Line,”  alternative  and 
programmed  systems. 


*  All  cost  elements  related  to  the  total  cost  of  ownership  for  the  life  of  the  program 
should  be  considered. 
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SECTION  6 


Degree  of  Risk 


6.0  General 

PTA’s  in  the  past  have  sometimes  been  based  on  very  tenuous  data  but. 
were  written  in  such  a  way  that  the  fulfillment  of  the  basic  requirement 
seemed  practically  assured.  If  this  lends  to  issuance  of  n  SOR,  a  great  deal 
of  difficulty  may  ensue.  ONO  must  be  given  as  accurate  an  appraisal  as 
possible  of  the  prospects  for  success  for  the  proposed  development. 

6.1  Contents 

In  this  section  an  estimate  of  the  degree  of  risk  involved  for  each  of 
the  approaches  will  be  presented.  In  assessing  the  degree  of  risk  involved 
it  should  be  stated  whether  primarily  engineering,  rather  than  experimental, 
effort  is  required,  and  whether  the  technology  is  sufficiently  in  hand  to  proceed 
with  a  systems  development.  The  principal  developmental  problems  or  high 
risk  areas  inherent  in  the  “Base  Line”  and  alternative  system  approaches 
under  consideration,  should  be  listed  and  discussed  in  their  order  of  impor¬ 
tance.  For  PTAs  submitted  in  support  of  an  ADO  oriented  project,  this 
section  should  also  be  used  to  specify  the  nature  and  extent  of  the  feasibility 
program  being  proposed  as  well  as  to  specify  the  end  (or  decision)  point 
of  the  project,  with  reasons  why  the  specific  program  and  end  points  were 
chosen.  This  is  in  contrast  to  a  PTA  supporting  an  SOR  oriented  project,  in 
which  case  the  emphasis  of  this  section  should  be  mostly  on  a  treatment  of 
the  principal  development  problem  areas. 

6.2  Minimizing  Risk 

It  is  usually  advantageous  from  the  degree  of  risk  standpoint  to  make 
maximum  use  of  existing,  proven  components,  designs  and  techniques  par¬ 
ticularly  where  only  marginal  improvement  can  bo  obtained  from  newer 
developments.  There  are  usually  advantages,  also,  in  the  areas  of  cost, 
logistics  and  personnel  training.  All  such  usage  should  be  discussed 
prominently. 


6A  Dependence  on  other  Developments 

The  extent  to  which  the  success  of  a  particular  development  hinges  upon 
other  developments  must  be  assessed.  Where  the  development  addressed  in 
a  PTA  is  to  any  degree  dependent  on  other  programs,  the  PTA  should  give 
all  pertinent  available  particulars  concerning  this  dependence,  proposed 
methods  for  monitoring  progress  of  the  other  development,  and  the  possible 
courses  to  redirect  the  dependent  program  should  the  other  program  fail 
to  satisfy  its  wants. 

6.4  Plans  to  Meet  Exigencies 

The  PTA  should  candidly  discuss  the  effect  of  failure  of  any  particularly 
difficult  design  goal  of  the  development  to  materialize  as  planned.  The 
trade-offs  of  possible  “fixes”  should  be  addressed. 


Degree  of  Risk  Cheek  List 


1.  Estimate  of  degree  of  risk  for  all  approaches. 

2.  Principal  development  problems  and/or  high  risk  areas. 

3.  Nature  and  extent  of  feasibility  program  for  ADO-oriented  Projects, 

4.  End  point  or  Decision  point  for  ADO-oriented  Project  with  reasons  for 
choosing. 

5.  Dependence  on  other  developments  and  proposed  methods  of  hedging  if 
these  developments  fail  to  materialize. 

6.  Plans  to  meet  exigencies  if  high  risk  developments  do  not  materialize 
as  planned. 


SECTION  7 


© 

Compatibility 

7.0  Equipment  Interfaces 

The  interfaces  between  tlie  equipment  proposed  to  be  developed  in  the 
PTA  and  other  associated  equipment  must  be  defined.  Where  it  is  impossible 
to  concisely  define  an  interface,  the  program  planned  to  resolve  the  problem 
areas  should  be  described.  The  current  status  and  cognizant  agency  of  all 
associated  systems  and  sub-systems  should  bo  indicated  in  a  table.  The  effect 
of  associated  sub-systems  in  meeting  the  system  requirements  should  be 
defined.  Steps  required  to  coordinate  the  new  development  with  cognizant 
agencies  for  associated  equipments  should  be  discussed.  Any  significant  change 
in  military  characteristics  of  existing  ships,  vehicles,  equipment,  or  facilities 
should  be  indicated. 

7.1  Electromagnetic  Interference 

The  proliferation  of  various  equipments  using  portions  of  the  electro¬ 
magnetic  energy  spectrum,  has  made  it  imperative  that  each  new  piece  of 
equipment  or  system  be  critically  examined  for  its  possible  interaction  with 
other  existing  or  projected  usage  of  the  electromagnetic  spectrum.1  This 
must  be  done  at  the  earliest  possible  time  in  the  development  process  for  new 
equipment.  Therefore,  a  PTA  for  such  systems  or  equipment  must  address 
itself  to  the  problem  using  all  available  data.  This  type  of  development  must 
be  coordinated  with  other  services  and  all  other  users  of  the  electromagnetic 
spectrum.  Compatibility  also  relates  to  other  interface  problems  such  as 
space  required  and  available,  special  support  equipment  requirements,  special 
environmental  requirements,  shock  and  vibration  requirements,  and  other 
requirements  such  as  electrical  current,  water,  steam,  ventilation,  fuel,  etc. 
Weight  may  be  a  problem  depending  upon  where,  the  equipment  is  to  be  used. 
Toxic  fumes  or  dangerous  radiation  may  be  produced.  All  these  and  many 
more  must  be  considered  and  discussed  candidly  in  the  PTA. 


‘  See  OPNAVINST  3010.0  Series  for  Electrical/Electronlc  Compatibility  requirements. 
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7*2  Other  Compatibility  Problems 

In  addition  to  the  interlace  problems  already  mentioned,  the  logistical 
support  required  by  the  new  development  must  be  considered.  The  degree 
of  susceptibility  to  countermeasures  is  another  area  of  concern  that  should 
be  addressed.  And  perhaps  the  biggest  compatibility  question  of  all  is  just 
how  well  will  a  new  system  fit  into  the  overall  Navy  forces  in  terms  of  its 
ability  to  support  and  augment  other  systems,  and  how  much  support  does 
it  require  from  other  systems.  When  it  is  designed  to  fill  a  gap  between  other 
systems,  does  it  barely  do  the  job  or  does  it  overlap  the  other  systems?  In 
the  case  of  overlapping  systems,  is  the  redundancy  useful  and  desirable 
operationally  and  costwise? 

A  question  of  the  greatest  importance  considering  the  large  spectrum 
of  possible  combat  situations  facing  the  Navy,  is  the  compatibility  of  the 
system  to  off-design  conditions  of  operational  environment,  and  the  sensitivity 
of  the  system’s  effectiveness  to  these  conditions  which  are  different  from 
those  for  which  the  system  is  optimized. 
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Compatibility  Check  List 

1.  Electromagnetic  energy  spectrum  compatibility  investigations  and  co¬ 
ordination  with  other  using  agencies,  including  reference  to  appropriate 
standards. 

2.  Space  required  and  available. 

8.  Weight  limitations. 

4.  Special  support  equipment. 

5.  Environmental  factors. 

a.  Humidity 

b.  Temperature 

c.  Pressure  requirements 

8.  Shock  and  vibration  (including  noise). 

7.  Electric  current  requirements. 

8.  Water  requirements. 

9.  Steam  requirements. 

10.  Ventilation  requirements. 

11.  Fuel  requirements. 

12.  Emission  Control  ( EMOON )  requirements. 

13.  Hazards  of  Electromagnetic  Radiation  to  Ordnance  (HERO)  require- 
menta 

14.  Fite  protection  requirements. 

15.  Toxic  fumes  produced. 

16.  Harmful  radiation  produced. 

17.  Logistical  support  requirements. 

18.  Countermeasures  susceptibility. 

19.  Stable  platform  requirements. 

20.  Magazine  storage  requirements. 

21.  Support  to  other  systems. 

22.  Support  required  from  other  systems. 

23.  Effect  of  off-design  conditions  of  operational  environment. 

24.  Human  Factors  Requirements. 
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SECTION  8 


Manpower  Considerations 


8.0  General 

Manpower  considerations  resulting  from  the  introduction  of  new  and 
ever  more  complex  systems,  have  av,  important  effect  on  such  systems  effec¬ 
tiveness  factors  as  reliability,  operability,  maintainability,  and  performance. 
Our  modern  tools  of  war  must  K  designed  from  the  start,  taking  into 
account  the  men  who  must  operat'  and  maintain  them.  An  optimum  system 
should  make  maximum  use  of  mao’s  capabilities  and  minimize  the  effects 
of  his  deficiencies.  The  human  operator  and  maintainor  can  be  considered 
as  elements  functioning  together  with  machine  elements  as  a  total  system. 

Human  factors  studies  on  such  subjects  as  human  engineering  and  per¬ 
sonnel  and  training  requirements,  should  be  conducted  by  sftecialists  in  these 
matters.  Lack  of  expert  consultation  in  the  formulative  stage  will  be 
apparent  in  the  PTA.  It  is  strongly  advised  that  the  human  engineers  and 
design  engineers  of  the  Principal  Development  Activity  discuss  personnel 
and  training  implications  of  all  PTA’s  with  the  Bureau  of  Naval  Personnel 
(BUPERS).1  (See  paragraph  8.8.)  Some  may  require  little  or  no  input 
from  BUPERS  while  others  may  have  very  important  manpower  implications. 

8.1  Integration  of  Manpower  Considerations  into  System  Development 

Effective  systems  require  that  manpower  considerations  be  integral  to 
system  design  in  all  stages  of  system  development.  It  is  recognized  that  in 
initial  stages  of  system  conceptualization,  human  engineering,  personnel  and 
training  considerations  are  extremely  fluid  and  subject  to  change.  This  does 
not  negate  the  requirement  for  providing  such  information  as  can  be  devel¬ 
oped,  which  will  form  the  basis  for  more  precise  research  to  he  carried  out 
as  the  system  design  becomes  more  stable.  Manpower  considerations  should 
be  treated  in  proper  perspective  as  vital  trade-off  elements  throughout  the 
total  process  of  system  development. 

Additionally,  manpower  planning  must  be  started  at  an  early  point  in 
the  development  cycle  because  of  the  considerable  lead  time  required  for 
personnel  planning  and  implementation.  First  there  must  be  a  determination 
of  required  manning  in  terms  of  numbers  and  skills.  Later  steps  include 
the  acquisition  of  personnel  suited  to  the  tasks,  establishing  training  centers 


1  SECNAV1NST  5430.07  assigns  specific  duties  and  responsibilities  tor  sdministration 
of  the  Department  of  the  Navy  Research,  Development,  Test  and  Evaluation  (RDT&B) 
program.  See  paragraphs  3.c.(l)(b),  3.o.(l>(e),  3.f.(3>,  3.f.(5),  and  3.f.(0). 
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and  staffs,  compiling  training  equipment,  devices  and  aids,  preparation  of 
manuals,  and,  Anally,  doing  the  actual  training.  Another  important  reason 
for  timely  personnel  planning  is  the  extreme  difficulty,  and  perhaps  impos¬ 
sibility,  of  solving  some  personnel  problems  that  are  not  identified  until  a 
development  has  reached  a  fairly  advanced  stage. 

&2  Human  Factors  in  System  Development 

Human  factors  refers  to  a  system  of  thinking  and  acting  which  is  geared 
toward  the  optimization  of  the  interaction  of  man  and  other  system  com- 
poiKWts.  This  may  be  accomplished  through  system  design,  organization, 
training,  srtd  the  like.  Human  engineering  is  the  sub-discipline  of  human 
factors  which  deals  with  the  specific  relationships  of  man  to  the  hardware 
element,  i.e.,  determination  of  functions,  design,  workspace  layout,  test  points, 
maintainability,  etc.  Personnel  and  training  research  is  the  sub-discipline 
of  human  factors  which  deals  specifically  with  examining  the  human  require¬ 
ments  which  a  given  system  design,  or  alternative  systems  designs,  will 
impose,  and  relating  these  requirements  to  the  Navy’s  capability  to  meet 
them  in  terms  of  quantitative  and  qualitative  criteria,  training  programs, 
etc.  Personnel  and  training  research,  as  well  as  human  engineering  for 
proposed  weapon  and  support  systems,  must  begin  at  the  PTA  stage  of 
system  development  if  maximum  system  performance  and  reliability  is  to 
be  achieved. 

The  objectives  of  Human  Factors  Keseareh  in  system  development  are 
as  follows: 

1.  Optimize  system  performance  by  ensuring  proper  mix  and  match 
between  man  and  the  rest  of  the  system. 

2.  Ensure  the  safety  and  survival  of  personnel  performing  in  a  systems 
framework. 

3.  Maximize  human  motivation  and  morale. 

Requirements  to  achieve  these  objectives  involve  fitting  the  man  to  the  job 
requirements  as  well  as  fitting  the  job  to  the  man,  and  through  research 
and  testing  determine  whether  the  best  “fit”  has  been  obtained. 

AS  Nature  of  Human  Engineering  Studies  in  the  PTA  Stage 

1.  Analysis  of  systems  functions  that  can  or  must  be  performed  by  man. 

2.  Trade-off  studies  involving  allocation  of  systems  functions  between 
men  and  equipment. 

3.  Identify  man-machine  interfaces  including  operating  and  maintenance 
considerations. 

4.  Analysis  of  personnel  aspects  of  equipment,  procedures,  facilities  and 
environment  including  life  support  facilities. 

5.  Performance  of  overall  system. 

0.  Causes  of  deficiencies  in  performance, 


8.4  Purpose  and  Nature  of  Personnel  and  Training  Research 

Effectiveness  of  Naval  Systems  is  predicated  in  part  o».  the  ability  of 
the  Navy  to  meet  the  ever-increasing  personnel  requirements  demanded  by 
those  systems.  Numbers  available,  qualitative  distribution,  and  training  re¬ 
sources  are  important  constraints  on  system  performance.  The  Navy  has 
been,  and  is,  faced  with  a  qualitatively  distributed  manpower  shortage.  This 
shortage  becomes  more  serious  as  the  state  of  technological  art  improves,  in 
that  qualitative  personnel  requirements  become  greater,  whereas  qualitative 
personnel  inputs  remain  relatively  constant.  Relatedly,  the  increasing  com¬ 
plexity  of  systems  strains  an  already  existing  training  problem. 

Basically,  personnel  and  training  research  answers  questions  concerning 
the  number  of  people  required,  the  capabilities  these  people  should  possess, 
the  time  at  which  such  personnel  are  needed,  how  they  are  obtained,  from 
where,  how  they  are  organized,  training  objectives  and  the  requirements 
for  their  fulfillment,  and  what  the  requirements  are  for  testing  and  evaluation 
of  such  personnel.  The  goal  of  such  an  analysis  is  to  match  system  personnel 
and  training  requirements  with  existing  resources  and  the  existing  Naval 
personnel  structure  in  terms  of  both  capabilities  and  number  of  people 
required.  Personnel  and  training  research  and  system  design  are  interacting 
factors.  Changes  in  desigit  or  design  concepts  may  affect  personnel  and 
training  considerations,  and  conversely,  constraints  deriving  from  personnel 
and/or  training  considerations  may  require  modifications  irr  system  design. 

&5  Objectives  of  Personnel  Research  at  the  PTA  Stage 

When  alternative  system  approaches  have  been  developed  sufficiently  to 
satisfy  information  requirements  of  a  PTA,  there  should  be  enough  informa¬ 
tion  available  to  determine  initial  comparative  personnel  and  training  require¬ 
ments  considerations.  The  objectives  of  personnel  research  at  this  stage  are: 

1.  To  examine  the  system  functions  to  be  performed  by  man; 

2.  To  assess  the  implications  of  these  functions  in  terms  of  the  number 
of  personnel  who  would  be  required  to  fulfill  the  requirements,  the 
capabilities  that  the  personnel  would  have  to  possess,  and  the  new 
training  demands  that  would  have  to  be  met; 

3.  To  relate  these  requirements  to  the  Navy’s  ability  to  meet  them; 

4.  To  provide  a  concrete  basis  for  estimating  the  human  resources 
feasibility  of  proposed  approaches  and  for  using  these  estimates  as 
sound  trade-off  criteria  in  relation  to  other  system  parameters; 

5.  To  develop  and  record  information  ns  a  basis  for  subsequent  personnel 
and  training  research. 
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8.6  Coordination  with  Bureau  of  Naval  Personnel 

The  Bureau  of  Naval  Personnel  (BUPERS)  is  sponsoring  procedures 
to  insure  the  integration  of  personnel  acquisition  and  training  in  the  planning, 
design  and  development  phase  as  w  ill  as  in  the  operation  and  maintenance 
phase  of  Naval  systems.  A  close  liaison  is  desirable  in  the  PTA  stage  among 
the  human  engineers  and  the  system  engineers  of  the  Principal  Development 
Activity,  and  the  research  analysts  of  the  New  Developments  Research 
Program  of  BUPERS. 

8.7  Consultation  with  Naval  Training  Devices  Center 

In  system  developments  which  appear  to  involve  development  of  new 
training  devices,  the  Naval  Training  Devices  Center  should  be  consulted. 

8.8  Content 

The  PTA  provides  the  first  opportunity  to  examine  the  manpower  impli¬ 
cations  of  given  system  approaches.  Each  approach,  therefore,  should  be 
discussed  in  terms  of  all  available  human  factors  information.  Procedures 
required  to  provide  adequate  reliability,  operability,  maintainability,  and 
supportability  which  are  related  to  manpower  considerations,  should  be 
discussed. 

Information  developed  as  a  result  of  objectives  shown  in  paragraphs 
8.3  and  8.5  should  be  included,  as  should  any  requirements  for  retraining 
or  special  training  devices.  In  addition,  a  narrative  summary  of  Human 
Factors  RDT&E  efforts  which  will  be  required  during  the  development 
programs,  the  technical  data  requirements  for  support  of  these  efforts,  and 
description  of  studies  already  completed,  both  in  exploratory  development 
and  in  other  related  programs,  should  be  included. 

Typical  trade-offs  in  personnel  feasibility  of  alternative  technical 
approaches  involve  such  items  as  the  following: 

1.  Technically  desirable  equipment  features  vs.  availability  of  Navy 
personnel  to  operate  and  maintain  the  desired  features. 

2.  Cost  reduction  features  vs.  availability  of  personnel  with  the  required 
skill  levels. 

3.  Time  savings  vs.  personnel  skill-level  and  availability  requirements. 

4.  Use  of  automated  features  vs.  increased  demand  for  skilled  manpower. 

5.  Simplicity  of  design  vs.  complexity  of  operator  and  maintenance  tasks. 

6.  Claimed  personnel  reduction  vs.  experimental  manning  requirements. 

7.  Cost  effectiveness  considerations  vs.  morale  and  retention  considerations. 
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Personnel  and  Training  Considerations  Cheek  List 

1.  Qualitative,  quantitative  personnel  requirements. 

2.  New  training  demands. 

3.  Personnel  and  training  tradeoff  criteria. 

4.  Human  resource  feasibility  of  alternative  approaches. 

5.  Special  training  device  requirements. 

6.  Human  factors  study  requirements. 

7.  Operability  factors. 
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SECTION  9 


Reliability  and  Maintainability 


9.0  General 

Reliability  and  maintainability,  which  are  to  a  great  extent  interde¬ 
pendent,  have  become  probably  the  greatest  problem  area  in  the  fleet.  To  a 
large  extent  reliability  and  maintainability  must  be  designed  into  equipment 
as  it  is  very  difficult  to  improve  either  to  n  marked  extent,  after  a  piece  of 
equipment  has  been  manufactured  and  installed.  Since  a  piece  of  equipment 
is  no  more  reliable  than  its  least  reliable  part,  very  careful  consideration 
of  reliability  and  maintainability  of  each  component  must  be  considered  very 
early  in  the  evolutionary  process.  The  Advanced  Development  stage  is 
none  too  soon. 

9.1  Contents 

A  PTA  should  contain  all  information  available,  either  from  experimental 
work  or  from  similar  types  of  equipment  or  simply  conjecture,  as  to  the 
reliability  and  maintainability  implications  of  the  proposed  approaches.  In 
addition,  the  PTA  should  discuss  those  steps  which  should  be  taken  during 
the  development  of  the  various  approaches  to  insure  adequate  reliability  and 
maintainability.  Special  attention  will  be  given  to  the  reliability  and  main¬ 
tainability  provisions  of  the  TSOR.  Reliability  and  maintainability  goals 
and  requirements  should  be  defined. 

Although  it  is  not  expected  that  the  PTA  treatment  of  reliability  and 
maintainability  can  be  done  in  the  same  detail  as  in  a  TDP,  the  same  general 
rules  apply.  The  closer  that  it  is  possible  to  approach  the  TDP  requirements, 
the  easier  it  will  be  later  should  a  TDP  be  required  for  the  proposed  devel¬ 
opment.  Section  10,  “Reliability  and  Maintainability  Plan”  from  the  TDP 
guide  is  reproduced  in  Appendix  C  as  a  reference. 
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Reliability  and  Maintainability  Check  List 


(See  “TDP  Check  List,  Section  10,  Reliability  and  Maintainability  Plan" 

in  Appendix  0.) 

1.  Analysis  of  operational  problem  to  establish  reliability  and  maintainability 
goals  or  requirements, 

2.  Analysis  of  reliability  of  components  and  isolation  of  probable  trouble 
spots. 

3.  Analysis  of  maintainability  of  components  and  determination  of  possible 
problem  areas. 

4.  Estimation  of  reliability  of  components  and  overall  system. 

5.  Estimation  of  mean  time  to  repair  of  components  and  overall  systems. 

6.  Discussion  of  use  environment  and  its  effect  on  reliability  and  main¬ 
tainability. 

7.  Source  of  data  used  in  estimation  of  reliability,  and  maintainability. 

8.  Data  available  along  with  source  and  data  which  should  be  obtained  by 
further  investigation. 

9.  Reliability  ar.d  Maintainability  assurance  program  to  insure  adequacy. 
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SECTION  10 


Summary  and  Recommendation 


10.0  General 

This  section  is  probably  the  most  important  in  the  entire  PTA  and  its 
contents  should  be  most  carefully  considered  and  weighed.  Its  contents  should 
be  given  very  wide  exposure  to  all  interested  parties  within  the  NMSE  and 
other  interested  offices  and  bureaus  to  assure  that  all  possible  conflicts  are 
addressed.  Coordination  with  other  services  having  an  interest  should  be 
accomplished. 

10.1  Contents 

This  section  states  which  type  of  CNO  response  is  sought  (ADO— SOlt) 
and  under  which  RDT&E  category  the  development  should  be  pursued.  For 
those  projects  meeting  formal  Contract  Definition  thresholds,  a  brief  summary 
should  be  included  of  the  steps  already  performed  or  planned  for  Concept 
Formulation  (prerequisite  for  initiation  of  Engineering  Development)  given 
in  DOD  Directive  3200.9  Series.  If  other  PTA’s  exist  or  are  being  produced 
which  are  related  to  this  PTA,  they  should  be  described  and  the  relationship 
explained  with  a  recommendation  concerning  the  several  documents  as  a 
group.  It  should  summarize  salient  points  with  respect  to  the  performance 
capability,  military  usefulness,  financial  acceptability,  technical  feasibility 
and  timeliness  of  the  various  systems  and  make  a  recommendation  as  to  the 
preferred  system  from  among  the  various  alternative  approaches.  Estimated 
development  funding  required  each  year  will  be  presented  for  the  recommended 
technical  approach.  Overall  program  funding  implications  of  the  PTA 
should  be  given  due  consideration;  in  particular,  where  other  work  may  have 
to  be  curtailed  in  order  to  proceed  with  the  proposed  development  work. 
A  preliminary  schedule  of  major  milestones  in  the  development  program 
should  be  shown  in  time  sequence. 

In  cases  whore  PTAs  must  cor  '•*»•  a  number  of  alternatives  to  the 
uB&se  Lino  system,  it  may  lie  desi.-i  .  to  generate  an  evaluation  matrix 
which  evaluates  each  system  considered,  against  a  series  of  evaluation  criteria 
selected  to  achieve  a  qualitntive/quant  dative  presentation  of  u  cost  effectiveness 
comparison.  Such  a  sheet  would  lie  part  of  this  summary. 

Comment  may  also  lie  included  here  of  a  type  which  the  submitting 
Bureau  might  otherwise  include  in  a  transmittal  letter  to  CNM  or  CNO. 

This  section  may  lie  marked  by  a  hard  divider  or  color  coded  for  easy 
location  and  access. 


MUX 


10.2  Comment  on  Requirement 

The  investigations  leading  to  the  PTA  may  indicate  desirable  deviations 
in  performance  or  other  characteristics  from  that  given  in  requirements 
documents.  Any  such  deviation  should  be  noted  here.  This  applies  to  too 
stringent  requirements,  as  well  as  cases  where  it  is  felt  that  more  capability 
should  or  could  be  obtained  in  the  development. 


Summary  and  Recommendation  Check  List 

1.  Response  sought  from  CNO(ADO-SOR). 

2.  Recommend  RDT&E  Category  for  development  (Advanced  Development, 
Engineering  Development,  etc.). 

3.  Related  developments  and  PTA’s  description  and  relationship  with  group 
recommendation. 

4.  Summary  of  performance  capability,  military  usefulness,  financial  accept¬ 
ability,  technical  feasibility,  and  timeliness  of  various  systems. 

5.  Funding  totals  by  fiscal  years  for  each. 

6.  Recommend  preferred  system. 

7.  Overall  program  funding  implications  of  proposed  approaches. 

8.  Explanation  of  evaluation  criteria  used  for  selection  of  recommended 
systems. 

9.  Evaluation  matrix  showing  each  system  rated  against  evaluation  criteria 
explained  above.  Quantitative  and  qualitative  systems  effectiveness  should 
be  shown. 

10.  Additional  information  of  value  in  selecting  optimum  system. 
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References 

Reference  all  documents  from  which  information  contained  in  the  PTA 
was  derived  as  well  as  others  which  would  contribute  to  a  more  complete 
understanding  of  the  project  under  discussion. 
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SECTION  12 
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Appendix  (es) 

When  the  PTA  responds  to  a  requirement  document,  that  requirement 
document  should  be  included  in  the  Appendix. 

Any  section  which  threatens  to  exceed  a  reasonable  number  of  pages 
should  be  reorganized  to  enable  some  or  all  of  the  supporting  data  and 
discussions  to  be  placed  in  an  appendix.  No  PTA  should  exceed  30  pages 
up  to  and  including  Section  10,  Summary. 

Individual  Procurement  Feasibility  Plans  (in  structure  like  an  Advance 
Procurement  Plan1)  shall  be  prepared  for  each  alternative  approach,  and 
included  as  Appendixes  to  the  PTA.  These  plans  should  be  sufficiently 
detailed  to  provide  a  basis  for: 

a.  Evaluating  the  impact  of  the  alternative  on  procurement. 

b.  Evaluating  the  economic  differences  among  the  alternatives. 


1  Guidelines  for  advance  procurement  planning  are  found  in  SECNAV1NST  4200.18 
Series  and  NAVMATINST  4200.32  Series. 
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GPNAV1NST  3910.8  Series 


Insert,  copy  of  OPNAV  INST  3&10.8  Series 
here  in  the  guide  for  reference  in  preparing 
PTA’s.  It  does  not  have  to  be  included  as  part 
of  each  PTA. 


APPENDIX  B 
SECTION  7 
Block  Diagram 


7.0  General 

The  purpose  of  the  block  diagram  is  to  illustrate  in  pictorial  form,  the  rela¬ 
tionship  between  major  components  of  the  system  and  the  relationship  of  the 
system  to  other  systems  or  functions.  In  order  to  be  effective  it  is  important  to 
keep  the  diagram  uncluttered  of  lengthy  descriptions  and  most  titling  should  be 
kept  to  one  or  two  words. 

Each  major  sub-system  or  function  should  be  shown  as  a  block  with  its  ap¬ 
propriate  title  appearing  within  the  block.  To  emphasize  the  importance  or 
physical  size  of  any  function,  a  larger  block  than  others  should  be  used.  Func¬ 
tions  which  interface  with  each  other  should  be  connected  by  lines. 

Interfaces  may  take  on  a  number  of  forms  which  may  be  physical,  such  as 
electrical  or  mechanical  interfaces,  or  non-physical,  such  as  an  information 
flow.  A  single  line  should  be  used  to  connect  each  block  which  is  related  to 
another  block  for  each  type  of  interface.  Connecting  lines  should  be  coded 
on  a  legend  on  the  drawing  and  a  label  placed  above  the  line  to  describe  the 
characteristic  of  that  interface.  (Coding  should  take  the  form  of  solid,  dotted 
or  dot-dash  lines  for  each  type  of  interface.) 

Arrows  should  be  placed  on  the  connecting  lines  to  show  the  direction  of 
energy  flow  for  an  electrical  or  mechanical  Interface  or  the  direction  of  data  flow 
for  an  informational  interface.  The  point  of  the  arrow  should  terminate  on  a 
block  and  arrows  on  both  ends  of  an  interface  line  signify  a  two  way  exchange 
between  functional  blocks. 

The  block  diagram  should  be  organized  so  that  one  can  easily  find  the  in- 
put(s)  to  the  system  and  follow  the  flow  through  the  major  functions  blocks  to 
the  resulting  output. 

To  achieve  this  facility,  the  block  diagram  should  be  constructed  so  that  the 
major  line  of  internal  flow  runs  from  the  top  to  the  bottom  of  the  page  or  from 
left  to  right.  One  should  avoid  laying  out  &  block  diagram  which  requires 
looping  back  and  forth  or  up  and  down  to  follow  the  flow  through  the  system. 
This  mcam  that  ihe  number  of  blocks  shiuld  generally  not  exceed  6-8. 

In  designing  the  layout  of  the  block  diagram,  it  may  be  that  6-8  blocks  do 
not  adequately  describe  the  system  in  the  level  of  detail  desired  by  the  PDA.  This 
can  bo  resolved  by  provided  subsidiary  block  diagrams  which  are  drawn  on  a 
functional  level  which  is  part  of  the  overall  system  function.  For  example, 
the  overall  block  diagram  can  have  each  of  its  component  blocks  broken  down 
with  r.  sub-system  block  diagram  for  each  block.  This  sub-system  block  dia¬ 
gram  should  be  constructed  following  the  same  rules  as  the  overall  block 
diagram.  This  process  may  be  repeated  as  often  as  desired  but  it  is  suggested 
that  a  maximum  of  two  levels  should  be  employed  even  for  tho  most  complex 
system. 


At  times,  it  may  bo  possible  to  eliminate  the  need  for  a  second  level  of  block 
diagram  by  increasing  the  number  of  blocks  on  the  overall  block  diagram  to 
10  or  12.  This  practice  is  perferrod  since  it  results  in  a  single  page  drawing 
of  the  system,  Foldout  pages  can  be  employed  with  a  maximum  size  of 
16 x  10^  (a  double  page). 

Each  block  on  the  overall  block  diagram  should  be  numbered  for  reference. 
Blocks  on  sub-system  block  diagrams  should  be  numbered  with  the  number 
of  the  block  of  the  overall  block  diagram  followed  by  decimal  digits.  For 
example,  the  overall  block  diagram  may  contain  a  block  labeled  “Data  Link” 
»nd  numbered  1.0.  If  a  lower  functional  level  drawing  is  constructed  further 
breaking  down  “Data  Link”  each  block  should  be  numbered  1.1,  1.2, 1.3,  etc., 
in  the  sub-system  block  diagram. 

7.1  Overall  Block  Diagram 

The  overall  block  diagram  should  Le  constructed  in  such  a  in  annex'  that  a 
reviewer  of  the  TDP  may  quickly  ascertain  the  relationship  of  the  system 
to  other  systems  and  the  major  units  of  the  system  under  development.  In 
addition  to  following  the  general  guidelines  described  in  SECTION  7.0,  the 
major  flow  through  the  system  should  be  emphasized  with  a  heavy  connecting 
line  and  arrows  between  blocks  existing  in  the  major  flow  path. 

All  associated  sub-systems  should  be  illustrated  as  a  single  block  for  each 
associated  subsystem.  Appropriate  interface  lines  should  be-  shown.  Figure 
7-1  illustrates  a  Typical  Overall  Block  Diagram. 

Included  in  this  section  should  be  a  general  description  of  the  system  opera¬ 
tion  which  follows  the  flow  shown  on  the  overall  block  diagram.  This  narrative 
should  be  quite  brief  and  is  employed  to  provide  those  reviewers  who  are  not 
technically  oriented  with  a  general  picture  of  the  role  of  this  system  in  relation 
to  overall  DOD  objectives  and  programs.  This  description  should  refer  to 
specific  characteristics  of  the  SOB  or  ADO. 

The  blocks  appearing  in  this  diagram  need  ncl  represent  physically  realiz¬ 
able  units  or  systems  but  may  represent  functions  which  involve  both  equipments 
and  human  actions.  This  is  particularly  applicable  in  non-automated  systems 
where  human  decision  is  an  integral  part  of  the  system  operation.  The  general 
description  of  the  system  operation  should  include  reference  to  the  man-machine 
interface  and  critical  points  of  operator  information  requirements,  information 
flow,  decision  points,  stored  information,  operator  intervention  and  action 
alternatives.  The  overall  block  di agram  should  distinguish  between  equipment 
operation  tasks  by  phase  as  given  In  the  general  description  of  the  system.  An 
example  is  a  command  and  control  system  which  may  be  fully  automated  in  the 
data  acquisition  and  reaction  control  functions  but  may  depend  upon  human 
intervention  to  complete  the  overall  action  between  acquisition  and  reaction. 

7.2  Detailed  Block  Diagram 

Ibis  diagram,  as  stated  in  SECTION  7.0,  is  used  when  further  detailing  of 
the  system’s  description  is  required.  There  may  be  detailed  block  diagrams  for 
some  or  all  of  the  blocks  of  the  overall  block  diagram.  The  degree  of  detail  is 
a  decision  to  be  made  by  the  writer  of  the  TDP  and  will  vary  from  system  to 
system.  General  guidelines  cannot  be  established  to  aid  in  deciding  upon  the 
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detail  required.  However,  the  detail  illustrated  in  the  diagram  should  relate 
to  the  degree  of  detail  employed  in  SECTION  8,  Sub-System  Characteristics. 
That  is,  for  every  bloek  appearing  in  the  block  diagram,  a  portion  of  SECTION 
8  shall  appear  where  that  block  is  described. 

No  descriptive  material  should  be  included  in  this  section  relating  to  the  de¬ 
tailed  block  diagram  since  it  will  appear  in  SECTION  8.  Figure  7-2  illustrates 
a  Topical  Detailed  Block  Diagram. 
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SECTION  7 

Block  Diagram 

1,  Can  the  system  be  illustrated  using  6-8  blocks  in  overall  block  diagram? 

2.  If  answer  to  (1)  is  “no”,  have  detailed  block  diagrams  been  drawn? 

3.  Have  all  related  blocks  been  connected  by  interface  lines? 

4,  Does  each  block  contain  its  title? 
ft.  Is  each  block  numbered! 

a)  on  overall  block  diagram  1.0, 2.0,  etc, 

b)  on  detailed  block  diagram  1.1, 1.2,  etc. 

6.  Is  each  type  of  interface  coded  and  does  a  legend  for  the  code  appear  on 
the  block  diagram? 

7.  Are  all  interface  linos  labeled  with  arrows  showing  direction  of  flow  ? 

8.  Does  the  major  flow  through  the  system  exist  from  top  to  bottom  or  left  to 
right? 

9.  If  detailed  block  diagrams  are  drawn,  can  system  be  illustrated  with  an 
overall  block  diagram  of  10-12  blocks? 

10.  Has  the  major  flow  through  the  overall  block  diagram  been  emphasized 
with  heavy  lines? 

11.  Has  a  brief  description  of  the  overall  block  diagram  been  included  ? 

12.  Have  all  associated  sub-systems  and  their  interfaces  with  the  development 
system  been  illustrated? 

13.  Has  each  block  diagram,  overall  and  detailed,  been  labeled  and  numbered? 

14.  Does  the  labeling  of  the  blocks  in  SECTION  7  correlate  with  SECTIONS 
8  and  9? 

15.  Has  the  Block  Diagram  been  carefully  compared  with  the  Work  Breakdown 
Structure  to  assure  that  all  bey  elements  of  project  hardware  have  been 
identified? 
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SECTION  10 

Reliability  and  Maintainability  Plan 

10.0  General 

The  purpose  of  this  section  is  to  outline  a  plan  for  assuring  that  the  system 
being  developed  is  capable  of  meeting  stated  reliability  and  maintainability 
objectives.  Reliability  and  maintainability  are  two  major  factors  contributing 
to  System  Effectiveness.  (Table  10-1  illustrates  the  elements  in  an  overall 
plan.)  These  objectives  should  be  defined  quantitatively  herein  and  should  be 
based  upon  the  Operational  Readiness  goals  as  stated  in  the  SOR.  The 
objectives  should  be  examined  carefully  for  feasibility  of  achievement. 

This  section  should  carry  as  much  emphasis  ns  any  other  section  in  the  TDP 
as  reliability  and  maintainability  are,  in  fact,  performance  parameters  of  the 
system.  Since  every  element  of  the  system,  both  man  and  machine,  contributes 
to  the  overall  reliability  and  maintainability,  a  program  of  definition,  design, 
prediction,  monitoring,  and  evaluation  must  be  included  to  minimize  any  possi¬ 
bility  of  producing  a  technically  acceptable  but  operationally  unacceptable 
system. 

If  the  TDP  is  in  response  to  an  ADO,  the  reliability  and  maintainability 
objectives  do  not  need  to  be  defined  if  the  system  being  developed  in  responso  to 
the  ADO  is  not  to  be  a  prototype  model.  Nevertheless,  a  plan  should  be 
described  to  provide  some  degree  of  reliability  assurance  during  the  research 
phase.  This  plan  need  not  bo  definitive  in  the  quantitative  sense  but  should 
describe  a  program  which  makes  both  reliability  and  maintainability  factors 
to  be  considered  in  the  experimental  development  program.  A  minimum  re¬ 
quirement  is  a  clear  statement  of  the  reliability  and  maintainability  philosophies 
t«  be  followed. 

Table  10-1.  Elements  in  Reliability  and  Maintainability  Plan 
Reliability 

Feasibility  Analysis  for  Parameter  Values  in  SOR/ADO 

Mission  Profile 

Reliability  Goals 

Reliability  Modeling 

Reliability  Apportionment 

Reliability  Predictions 

Reliability  Measurements 

Component  Part  Reliability 

Environmental  Effects 

Storage  Considerations 
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Maintainability 

Feasibility  Analysis  for  Parameter  Values  in  SOIt/ADO 

Maintainability  Goals 

Maintainability  Modeling 

Allocation  of  Repair  Responsibilities 

Predictions 

Measurements 

Repairability  Status 

Repair  Techniques 

Nora:  These  elements  apply  to  man  segments  of  the  system  as  well  as  to  machine 
segments. 

Therefore,  this  section  should  define  plans  for  both  reliability  and  maintain¬ 
ability  assurance.  Each  plan  should  indicate  the  steps  to  be  followed,  the 
general  techniques  or  specifications  to  be  applied,  the  major  milestones  in  the 
program  and  the  responsible  parties  charged  with  establishment  of  goals  and 
monitoring  of  progress  toward  these  goals.  The  plan  should  include  a  reporting 
method  to  be  imposed  upon  contractors  in  support  of  the  plan.  The  quantitative 
objectives  for  reliability  and  maintainability  for  each  sub-system  should  be 
stated  as  well  as  the  overall  system  performance  in  all  of  its  operating  modes. 
It  is  recognized  that  quantitative  objectives  may  not  be  available  for  some  sys¬ 
tems  under  advanced  development,  for  those  systems  assumed  quantitative 
objectives  should  be  provided. 

The  overall  availability  of  the  final  system  h  a  function  of  its  quantitative 
reliability  expressed  as  Mean  Time  Between  Failure  (MTBF),  and  its  quanti¬ 
tative  maintainability  expressed  as  Mean  Time  To  Repair  (MTTR) ,  Because 
of  this  relationship  and  because  of  the  ultimate  interest  of  the  operating  forces 
in  System  availability,  the  PDA  should  define  plans  for  reliability  and  main¬ 
tainability  assurance  which  complement  each  other  in  such  a  manner  as  to 
insure  the  achievement  of  the  overall  availability  objective. 

10.1  Reliability  Assurance 

10.1.1  Reliability  Plan 

Figure  10-1  illustrates  the  major  phases  of  a  reliability  program.  In  the 
detailed  reliability  plan  the  Project  Manager  must  describe  the  procedures  and 
techniques  to  be  employed  during  each  phase  of  the  reliability  program. 

Furthermore,  one  must  make  certain  decisions  which  will  be  reflected  in  the 
TDP  in  regard  to  which  phases  of  the  reliability  program  may  be  downgraded 
and  which  may  be  emphasized  in  the  particular  reliability  plan  being  applied 
to  the  system. 

Prior  to  establishment  of  a  detailed  reliability  plan,  the  PDA  must  answer 
the  following  question :  “Is  reliability  prediction  an  adequate  technique  for 
assurance  of  reliability  or  will  a  reliability  demonstration  be  required?”  The 
answer  to  this  question  will  establish  the  overall  philosophy  of  the  reliability 
plan  and  a  number  of  important  factors  shou'd  be  weighed  when  considering 
the  question. 

To  evaluate  these  factors,  it  is  best  to  examine  a  typical  reliability  plan  as 
illustrated  in  Figure  10-2.  The  figure  illustrates  major  events  occurring  in 


Figure  10-2.  Brents  In  a  Reliability  Plan. 


gram  form  in  SECTION  7  of  the  TDP.  From  this  overall  block  diagram, 
the  Project  Engineer  will  devise  functional  or  model  diagrams  which  will 
illustrate  the  system  in  its  various  operating  modes. 

10X4  'Apportionment  of  Sub-System  Reliability  Objectives 

The  overall  system  reliability  goals  are  applied  to  the  various  functional 
models  of  the  system  and  sub-system  and  unit  MTBF’s  or  other  measures  (i.e., 
cycles,  etc.)  of  success  are  arrived  at  by  the  Project  Engineer,  These  objec¬ 
tives  are  determined  by  considering  relative  complexity  of  each  unit  or  sub- 
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system  and  the  state-of-the-art  for  that  particular  type  of  device.  At  this 
time  the  Project  Engineer  may  consider  the  use  of  redundancy  either  in  cir¬ 
cuits,  units  or  sub-systems  if  his  experience  indicates  that  state-of-the-art 
limitations  dictate  a  need  for  such  redundancy  in  order  to  achieve  the  system 
reliability  goal. 

Figure  10-8  illustrates  a  tcclinique  of  reliability  apportionment.  As  an  ex¬ 
ample  of  the  application  of  this  technique,  assume  that  a  system  consists  of 
sub-systems  A,  B  and  C  which  function  as  shown  in  Figure  10-3  and  that  the 
overall,  P„  mission  reliability  for  the  system  for  a  10-hour  mission  is  0.05. 
(The  mission  duration  and  reliability  goal  are  established  in  the  SOR.) 


I - 1 

I  (Redundancy)  | 


H 

I _ 


Pg  =  .95 


*  Pq  is  the  quantity  to  be  determined 

Figure  10-ft,  Apportionment  of  Reliability  Goals. 

This  Pj  is  .the  product  of  the  probability  of  survival  of  eacli  sub-system.  If 
PA  is  the  probability  of  survival  objective  for  system  A,  and  PB  is  the  proba¬ 
bility  of  survival  for  system  B,  etc.,  then  Ps  can  bo  expressed  as 

Ps  —Pa  y^P bX.Pc 


-j 
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Based  upon  experience  And  state-of-the-art,  assume  that  P4  can  be  set  at 
0.09  and  P,  at  0.08.  The  determination  of  the  reliability  goal  for  system  0,  Pc, 
can  be  found  from 

p  _ 

Fc  Pj&l 

Using  the  figures  from  above 

p  P  a  .08  ‘05  ai»a 

0  P*XPs  .90X.08  .07 

Now  the  MTBF  for  each  sub-system  is  related  to  the  probability  of  survival 
and  the  mission  duration  by  the  relationship4 
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(See  Appendix  D  for  Reliability  Nomograph) 


whero  P3= probability  of  survival 

#=base  of  natural  logarithms,  2.718 
1 


<= mission  duration  in  hours 


By  substituting  the  allotted  Pa  and  P*,  and  the  computed  Pc  in  this  equa¬ 
tion,  the  MTBF  goal  for  each  sub-system  may  be  arrived  at,  yielding 

MTBFx— 1,000  hours 

MTBF, =500  hours 

MTBFc=»470  hours 

These  figures  will  bo  used  as  a  design  parameter  in  the  specification  of 
each  sub-eystem. 

If,  as  the  development  progresses,  the  expected  P4  of  system  B  is  deter¬ 
mined  to  bo  0.07  rather  than  0.98,  a  reapportionment  of  reliability  objectives 
will  tako  place. 

Either  P*  orPcor  both  could  be  increased  to  accommodate  the  deficiency 
in  the  performance  of  system  B  or  ns  an  additional  alternative,  system  B  can  be 
made  redundant  as  illustrated  in  Figure  10-3.  The  choice  of  alternative  must 
be  made  considering  the  relative  cost  of  each. 

If,  for  example,  the  choice  is  made  to  increase  the  reliability  objective  for 
system  C,  the  following  apportionment  will  result: 


Probability  of  Survival 

MTBF  Objective  for  a  10-Hour  Mission 

P»=. 97  (revised) . 

333  hours 

Pa~- 00  (unchanged) . 

1,000  hours 

Pc~  7  (.980)  revised . 

010  hours 

P«=.05  (unchange  .)__ . - 

196  hours 

•An  exponnnti.'J  relationship  is  assumed  to  apply.  Specific  cases  may  require  other 
distributions. 
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10.1.5  Determination  of  Applicable  Reliability  Prediction  and  Evaluation 
Techniques 

It  is  at  this  point  that  the  PDP  must  decide  the  answer  to  the  question  pre¬ 
viously  posed;  “Is  reliability  prediction  without  evaluation  adequate?” 

A  program  of  reliability  demonstration  of  necessity  will  involve  increased 
program  cost  and  possibly  a  lengthy  testing  period.  To  measure  the  MTBF 
of  a  sub-system  or  unit  with  high  confidence,  tho  sub-system  must  be  operated 
for  long  periods  with  enough  failures  occurring  to  provide  a  largo  enough 
statistical  sample  to  determine  tho  mean  operating  time.1  As  an  alternative  to 
this,  many  sub-systems  or  units  may  be  built  and  operated  concurrently,  thus 
outting  down  the  overall  time  to  collect  reliability  data.  But  tho  latter  alterna¬ 
tive  involves  tho  increased  cost  of  construction  of  additional  equipments. 

If  reliability  prediction  is  felt  to  be  adequate,  then  an  extensive  testing  pe¬ 
riod  or  tho  timo  and  cost  of  constructing  additional  equipments  are  avoided. 
However,  on  uncertainty  will  exist  concerning  the  ability  of  tho  final  system  to 
meet  tho  required  reliability  goals. 

Depending  upon  the  value  of  the  predicted  MTBF  relative  to  tho  required 
MTBF  and  the  confidence  in  the  basic  reliability  data  and  teolmiques  employed 
in  tire  prediction,  the  level  of  uncertainty  will  vary.  Certainly,  a  predicted 
mean  life  exceeding  tho  requirement  by  50  percent  or  greater  would  influence  the 
PDA  towards  reducing  the  reliability  testing  if  one  is  considering  such  a  course 
of  action.  On  the  other  hand,  a  prediction  close  to  the  requirement  may  prove 
influential  towards  the  opposite  decision. 

This  then  is  the  decision  to  be  made  by  the  PDA.  One  must  assess  the 
cost/time  vs.  confidence  level  tradeoff  to  determine  the  type  of  reliability  plan 
to  be  implemented. 

To  make  this  decision  the  Project  Engineer  should  provide  tire  PDA  with 
the  basic  data  concerning  number  of  units  required  for  a  reliability  demonstra¬ 
tion,  expected  tost  periods,  and  anticipated  confidence  levels. 


If  tho  PDA  decides  that  reliability  prediction  is  adequate  for  his  needs,  he 
should  discuss  the  factors  influencing  this  judgment  and  his  assessment  of  thoir 
cost  effectiveness  in  this  section  of  the  TDP.  Any  other  factors,  such  as  urgency 


in  obtaining  equipment,  which  might  influence  such  a  decision  shouia  bo  ex¬ 


plained  as  well. 


Once  this  decision  on  basic  philosophy  has  been  made,  the  PDA  should  indi¬ 
cate  which  documents  will  be  invoked  in  implementing  tho  reliability  plnn.  For 
oxample,  he  must  decide  if  he  will  roquiro  contractors  to  provide  predictions 
according  to  MID-STD-750  (The  DOD  Standard),  or  if  he  vii.  permit  con¬ 
tractors  to  submit  their  predictions  based  upon  other  military  or  commercial 
standards.  Tho  method  of  reporting  of  contractor  predictions  and  evaluations 
must  be  established  and  a  failure  repotting  program  should  be  imposed  upon 


1  As  an  Indication  of  the  amount  of  testing  Involved,  let  us  assume  that  one  wishes  to 
measure  tho  MTBF  of  a  system  with  a  confidence  level  of  00%.  If  tests  are  run  until  80 
failures  occur  and  If  tho  measured  MTBF  after  80  failures  Is  100  hours,  one  can  be  90% 
confident  that  the  actual  MTBF  Is  between  70  and  130  hours.  For  higher  levels  of  confidence 
or  to  decrease  the  expected  range  of  the  mean,  more  failures  must  be  experienced  hence 
longer  testing  periods  or  Increased  equipment  quantities  aro  required. 


the  contractor  whioh  requires  him  to  report  and  analyzo  the  cause  of  all  failures 
occurring  during  equipment  development.  Rather  than  establishing  a  reli¬ 
ability  plan  for  the  contractor,  the  PDA  may  elect  to  require  the  contractor 
to  submit  his  proposed  reliability  plan  to  the  PDA  for  approval.  The  TDP 
should  indicate  which  course  of  action  will  be  chosen.  If  this  course  of  action 
is  ohoson  a  schedule  for  submission,  roviow  and  approval  of  the  contractor’s 
plan  should  bo  established. 

Figure  10-4  is  a  chart  summarizing  most  of  tho  military  specifications  and 
standards  available  to  the  PDA  ns  supporting  documentation.  By  familiariz¬ 
ing  himself  with  tho  documents  defining  reliability  program  requirements  and 
those  defining  reliability  techniques  to  be  employed  in  design,  development 
and  production,  tho  PDA  should  be  able  to  in  voko  an  existing  specification  which 
will  closely  meet  his  particular  program  needs.  MIL-STD-T85  Roliability- 
Genoral  Specification  should  bo  reviewed  for  applicability  to  most  programs. 

10.1.6  Preparation  of  Equipment  Specification 

After  establishing  tho  general  philosophy  of  the  reliability  plan  and  de¬ 
termining  tho  applicable  documents,  a  section  invoking  those  documents  and 
procedures  is  included  in  tho  equipment  specification. 

Tho  required  MTBF  should  bo  included  in  tho  section  of  the  specification 
defining  performance  parameters  but  the  methods  to  bo  employed  in  predic¬ 
tion  and  evaluation  as  well  ns  any  special  requirements  on  contractor  monitor¬ 
ing,  review  and  reporting  should  be  inoluded  under  quality  assurance  provi- 
sions.  Tho  specification  also  should  detail  the  environmental,  reliability  and 
other  tosts  which  will  be  performed  on  the  equipment.  Tho  Dosign  Specs 
listed  in  Figure  10-4  include  ns  a  rule  environmental  requirements  which 
should  be  considered  for  the  particular  type  of  equipment  undor  consideration. 
Careful  consideration  should  bo  given  to  tho  expeoted  shipping,  storage  and 
operating  environment  of  tho  equipment  so  that  tho  environmental  tests  which 
are  invoked  are  compatible  with  the  conditions  of  tho  actual  environment. 

A  method  of  failure  reporting  and  analysis  should  be  invoked  within  the 
specification  to  assure  the  PDA  that  the  contractor  is  continually  applying  a 
program  of  quality  assurance  to  his  design. 

16.1.7  Proposal  Submission  and  Review 

The  next  step  in  any  reliability  plan  is  tho  review  of  contractor  proposals. 
As  an  aid  in  evaluating  the  contractor’s  submission  of  his  reliability  programs, 
the  PDA  should  refer  to  Figure  8-3,  Pages  3-11  and  3-12  of  NAVWEPS 
00-66-602  Reliability  Handbook  which  offers  a  convenient  checklist. 

This  chart  indicates  the  major  points  of  interest  to  the  Project  Engineer 
when  evaluating  proposals  and  determining  the  responsiveness  of  proposals. 

10.1.8  Contract  Award 

Included  in  tho  contractual  documentation  should  appear  tho  requirement 
to  follow  a  reliability  plan  os  agreed  upon  during  contract  negotiation.  Tiro 
requirement  may  appear  as  an  applicable  document  or  reliability  plan  in  the 
specification  or  it  may  appear  as  a  separate  contract  item  where  deliverable 
reports  are  required, 
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10.1.9  Initial  Reliability  Prediction 

Each  contractor  shall  be  required  to  submit  for  PDA  approval,  an  initial 
estimate  of  sub-system  reliability  immediately  upon  his  completion  of  the 
paper  design  of  his  equipment.  The  submission  shall  be  in  sufficient  detail 
as  to  permit  the  PDA  to  evaluate  the  validity  of  his  prediction  technique,  its 
application  and  its  results.  MID-STD-756,  should  be  reviewed  by  the  PDA 
for  applicability  in  this  phtse  of  the  program. 

10.1.10  System  Reliability  Prediction 

After  evaluating  each  contractor's  submission,  the  PDA  will  use  these  pre¬ 
dictions  to  estimate  the  reliability  of  the  system  in  its  various  operating  modes. 
Comparisons  will  be  made  between  the  predicted  reliability  in  each  mode  and 
the  reliability  goals  whicn  were  described  in  Section  10.1.1  herein. 

19.1.11  Possible  Reconfiguration  of  System 

As  a  result  of  the  comparison  between  predicted  system  reliability  and  the 
reliability  goals,  it  may  be  necessary  to  consider  &  reconfiguration  of  the  system. 
If  the  goal  exceeds  the  prediction,  or.e  may  consider  the  use  of  redundancy  of 
units  or  sub-systems  or  a  redesign  of  equipment  as  means  toward  increasing 
the  overall  predicted  reliability.  Another  possible  alternative  is  a  review  of 
the  goals  to  reduce  them  to  meet  the  prediction.  This  alternative  should  be 
considered  in  light  of  the  potential  increased  cost  in  providing  redundancy 
or  improving  the  equipment  design  to  enable  the  system  to  meet  its  initial 
reliability  objective. 

The  prediction  should  always  exceed  the  goal.  If  the  prediction  exceeds  the 
goal  by  a  margin  of  over  2  to  1,  a  potential  over-design  situation  exists. 
This  conclusion  is  dependent  upon  the  confidence  level  placed  in  the  prediction. 
This  confidence  level  must  be  based  upon  actual  prior  measurements  on  other 
projects  which  employed  the  same  basic  failure  rate  data  and  prediction  tech¬ 
niques.  Such  a  review  of  previous  results  should  provide  the  Project  Man¬ 
ager  with  an  indication  of  the  confidence  he  may  yd  ace  in  the  prediction.  For 
example,  a  compilation  of  actual  vs  predicteu  MTBF’s  may  indicate  that  the 
prediction  is  generally  about  75%  of  the  measured  MTBF.  If  this  factor, 
applied  to  the  prediction,  stiil  results  in  a  weighted  prediction  substantially 
exceeding  the  goal,  the  basic  design  should  be  reviewed  to  determine  if  any 
modification  can  be  made  which,  although  it  reduces  the  predicted  MTBF, 
may  also  reduce  the  cost.  Do  not  reduce  the  MTBF  by  design  changes  unless 
cost  or  other  benefits  are  evident  At  this  point  a  cost/effectiveness  study  should 
be  performed  to  provide  the  basic  tradeoff  data  upon  which  such  a  decision 
may  be  made. 

The  review  and  updating  of  system  configuration  should  be  a  process  which 
is  employed  after  completing  significant  events  in  any  phase  of  a  project. 
It  should  occur  during  a  reliability  program  whenever  predictions  or  meas¬ 
urements  result  in  overall  system  performance  which  is  not  in  accord  with 
system  reliability  goals. 

X0.1.12  Reliability  Design  Reviews 

As  the  design  of  the  equipment  progresses,  each  contractor  should  be  re¬ 
quired  to  perform  at  least  one  critical  reliability  design  review  before  freezing 


tlie  design.  Any  changes  in  equipment  configuration  or  major  component  com¬ 
plement  should  be  appraised  and  a  new  reliability  prediction  should  be  pro¬ 
duced  The  critical  items  of  appraisal  to  be  considered  during  such  a  review 
are  described  in  Paragraph  3.2.2.6  of  MIL-R-22732B  (SHIPS). 

As  a  result  of  this  review,  it  may  be  necessary  to  reconsider  the  system  con¬ 
figuration  as  described  in  Section  10.1.10  herein.  The  PDA  should  carefully 
monitor  and  evaluate  dm  predictions  and  failure  reports  from  all  contractors. 
Since  theso  predictions  will,  in  general,  not  be  available  concurrently,  the  PDA 
should  carefully  weigh  the  impact  of  each  contractor’s  prediction  upon  the 
reliability  goals  established  by  specification  for  each  other  contractor. 

10.1.13  Final  Sab-System  Reliability  Prediction 

When  all  design  changes  have  been  incorporated  into  the  equipment  and  a 
final  configuration  exists,  the  contractor  should  perform  a  final  reliability  pre¬ 
diction.  This  prediction  should  be  appraised  for  its  effect  upon  overall  system 
reliability,  as  are  all  predictions. 

If  required,  the  s/stem  configuration  should  be  reviewed  for  possible  modi¬ 
fication. 

10.1.14  Subsystem  Reliability  Demonstration 

When  a  program  of  reliability  demonstration  is  to  be  undertaken,  both 
unde1  development  and/or  production  contracts,  the  resulting  data  should  be 
evaluated  in  light  of  the  reliability  objectives. 

At  this  point  confidence  levels  in  the  measured  MTBF  can  be  quantitatively 
determined.  (For  details  of  this  technique  see  NAVWEPS  00-65-602  Re¬ 
liability  Handbook-Appendix  3.) 

A  final  computation  may  now  be  performed,  using  actual  data  on  sub-system 
reliability,  to  predict  system  reliability.  Again,  a  review  of  system  configura¬ 
tion  based  upon  a  comparison  of  goals  and  extrapolated  measurements  should 
be  made. 

As  each  succeeding  prediction  and  appraisal  is  performed  during  the  relia¬ 
bility  program,  the  impact  of  each  of  these  upon  system  configuration  should 
dimmish.  It  is  to  be  expected  that  major  changes  in  configuration  may  occur 
as  a  result  of  the  earlier  predictions  but  the  evaluation  of  the  effect  of  the  relia¬ 
bility  demonstration  on  overall  reliability  should  result  in  little  if  any  alteration 
to  the  system. 

A  number  of  techniques  of  reliability  demonstration  are  available  for  use 
during  this  phase  of  the  program.  MIL-STD-781,  “Test  Levels  and  Accept/ 
Reject  Criteria  for  Reliability  of  Non-Expendable  Electronic  Equipment,”  out¬ 
lines  a  series  of  environmental  test  levels  which  can  be  employed  for  the  purpose 
of  reliability  demonstration  NAVWEPS  00-65-502,  “Reliability  Testing,” 
Sections  6  and  7,  provide  useful  data  for  the  design  of  tests  for  reliability 
demonstration. 

10.1.15  System  Reliability  Demonstration 

This  phase  measures  the  validity  of  all  assumptions,  predictions  and  analy¬ 
sis  techniques  previously  employed. 

In  the  case  of  a  developmental  equipment,  tests  and  evaluations,  as  described 
in  SECTION  12  of  the  TDP,  are  the  vehicles  through  which  system  reliability  is 


demonstrated.  In  the  case  of  production  equipments,  the  final  in-service  opera¬ 
tion  provides  the  means  for  measuring  system  reliability.  Regardless  of  how 
closely  conditions  are  simulated,  and  performance  tests  are  planned,  it  is  opera¬ 
tion  under  actual  service  conditions  which  provides  the  technique  for  full 
evaluation.  It  is  here  that  the  maintenance  procedures  and  operating  pro¬ 
cedures  are  employed  to  stress  the  equipment  with  factors  not  existing  in  a 
laboratory  or  factory. 

Failure  reports  and  equipment  logs  should  be  prepared  in  accordance  with 
MIL-E-lfi400E»  Amendment  4,  Paragraph  3.1.8,  General  Specification,  Elec¬ 
tronic  Equipment,  Naval  Ship  and  Shore. 

These  reports  provid  i  a  meahs  for  measuring  system  reliability  with  high 
confidence  and  assist  in  the  determination  of  the  “true5’  MTBF, 

10.1.16  Determination  of  Overa  .,  System  Reliability 

After  the  “true”  reliability  a.  .  “true”  maintainability  of  the  system  have 
bom  determined  as  described  in  part  in  Section  10.1.15,  the  system  availablity 
may  be  determined  from  the  following  formula : 

MTBF 

Availability ^ MTBF + MTTR  X  ^ %  (See  Appendix  C  for  Avail¬ 
ability  N  omograph ) 

where  MTBF  (Mean-Time  Between  Failures)  is  the  mean  operating  time 
and  MTTR  (Mean-Time  to  Repair)  is  the  mean  down  time,  for  each  opera¬ 
tional  mode  of  the  system. 

This  is  the  final  step  in  the  reliability  plan. 

10.2  Maintainability  Assurance 

10.2.1  Maintainability  Plan 

The  Events  in  a  Maintainability  Plan  outlined  in  Figure  10-5  can  be  used 
as  a  basis  for  most  maintainability  plans.  As  in  the  Reliability  Plan,  the  PDA 
must  describe  the  procedures  and  techniques  that  will  be  employed  during  each 
phase  of  the  project  and  the  degree  of  emphasis  to  be  placed  on  each  event  The 
major  events  of  a  typical  maintainability  plan  are  described  in  the  following 
paragraphs  to  guide  the  PDA  in  making  maintainability  decisions  which  will  be 
reflected  in  the  TDP. 

10.2.2  Establishment  of  Maintainability  Goals 

It  is  the  responsibility  of  the  Project  Engineer  to  determine  the  system 
quantitative  maintainability  goal  within  the  framework  of  the  operational  and 
planning  information  outlined  in  the  SOR.  A  suitable  reference  guide  for  this 
task  is  NAVSHIPS  04324,  “Maintainability  Design  Criteria  Handbook  for  De¬ 
signers  of  Shipboard  Electronic  Equipment,”  This  document  describes  the 
various  factors  affecting  maintainability  and  the  mathematical  techniques  to  be 
employed  in  establishing  system  MTTR  values. 

10.241  Maintenance  Philosophy 

In  addition  to  providing  essential  data  for  the  Supportability  Plan,  and  the 
Personnel  and  Training  Plan,  the  maintenance  philosophy  provides  useful  in¬ 
formation  for  predicting  maximum  and  minimum  requirements  for  MTTR 
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And  for  the  allocation  of  the  overall  system  maintainability  measures  to  various 
functional  levels.  The  responsibility  for  developing  the  system  maintenance 
philosophy  is  assigned  to  the  Project  Engineer.  Useful  information  on  the 
relationship  of  elements  in  the  maintenance  cycle  to  maintainability  design  can 
be  found  in  NAVSHIPS  $4324. 

10X4  Qualification  of  Maintainability 

Development  of  numerical  measures  of  maintainability  for  inclusion  in  the 
TDP  can  be  accomplished  by  predictive  methods  based  on  information  provided 
by  the  system  maintenance  r  Mlosophy.  Typical  prediction  methods  and  ex¬ 
pected  ranges  of  MTTR  for  ious  repair  methods  can  be  found  in  the  main¬ 
tainability  evaluation  procedures  of  MIL-M-23313A  ( SHIPS)  or  MIL-S- 
28603. 

Since  system  availability  (A)  is  a  function  of  both  MTBF  and  MTTR, 

(A-  JM[TBF  >» 

MTBF + MTTR 

maximum  and  minimum  values  for  MTTR  should  be  stated  whenever  fixed 
values  are  not  specified.  This  will  afford  some  degree  of  tradeoff  between 
reliability  and  maintainability  design  for  a  specified  value  of  A.  Information 
regarding  MTBF-MTTR  tradeoff  possibilities  is  contained  in  NAVSHIPS 
94824. 

10X5  Maintainability  Apportionment 

The  allocation  overall  system  measure  of  maintainability  to  lower  order  ele¬ 
ments  of  the  system  can  be  accomplished  by  prediction  methods  described  in 
M IL-M-23B1S ( SHIPS ) ,  or  MIL-S-23608.  General  information  requirements 
and  the  mathematical  techniques  for  determining  maintenance  task  times  re¬ 
lated  to  each  functional  level  of  the  system  are  provided  in  this  document. 

10X6  Determination  of  Maintainability  Prediction  and  Evaluation  Tech¬ 
nique 

At  this  point,  factors  which  will  influence  the  PDA  decisions  regarding  re¬ 
liability  prediction  and  evaluation  will  also  affect  decisions  concerning  maintain¬ 
ability  prediction  and  evaluation.  The  alternate  approaches  to  maintainability 
assurance  which  will  be  possible  once  the  basic  philosophy  decision  has  been 
made,  parallel  those  described  (see  Section  10.1.4)  for  implementing  the  relia¬ 
bility  plan.  Some  of  the  maintainability  documents  which  may  be  invoked 
are  listed  in  Figure  10-4. 

10X?  Preparation  of  Equipment  Specifications 

All  maintainability  documents  and  procedures  to  be  invoked  must  be  in¬ 
cluded  in  the  equipment  specification.  In  defining  performance  parameters  in 
the  specification,  the  required  measures  of  MTTR  should  be  included  and  the 
quality  assurance  provisions  should  include  prediction,  evaluation,  monitoring, 
review  and  reporting  methods  and  requirements.  Maintainability  specifications 
must  give  due  consideration  to  human  factors  which  affect  system  performance. 
Contractors  should  be  cautioned  to  incorporate  human  resource  constraints  in 
their  design  for  maintainability.  The  specifications  fox  maintainability  re¬ 
quirements  contained  in  MILr-M-23318A(SHIPS)  are  typical. 
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10.2.8  Proposal  Submission  and  Review 

The  maintainability  program  submitted  by  the  contractor  should  be  re¬ 
viewed  jointly  by  the  Project  Manager  and  the  Project  Engineer  to  determine 
responsiveness  to  specifications. 

10.2.9  Contract  Award 

Maintainability  requirements  should  be  included  in  the  contractual  docu¬ 
mentation  in  the  manner  described  for  reliability  requirements  (see  Section 
10.1.7). 

10.2.10  System  Maintainability  Predictions  and  Design  Reviews 

Initial  maintainability  predictions  submitted  by  the  contractor  (s)  during 
the  design  planning  stage  of  the  system  research  and  development  phase  ate  used 
by  the  PDA  for  early  estimates  of  overall  system  maintainability.  Methods 
and  schedules  of  evaluation  to  be  used  during  the  early  design  stages  are  usually 
left  to  the  contractor  providing  compliance  with  specifications  in  the  final  design 
is  assured.  Maintainability  design  reviews,  whether  independent  or  integrated 
with  reviews  for  other  purposes,  provide  the  means  for  implementing  main¬ 
tainability  design  control  necessary  to  assure  (1)  meeting  the  specific  human 
factors  criteria  for  the  equipment  or  system  in  compliance  with  contract  require¬ 
ments,  and  (2)  changes  affecting  maintainability  design  are  handled  expe¬ 
ditiously.  The  final  maintainability  prediction(s)  by  contractor(s)  should  be 
analyzed  and  the  overall  system  maintainability  prediction  to  determine  if  the 
Specified  requirements  will  be  met.  System  reconfiguration  that  might  occur 
will  require  a  continuing  effort  of  maintainability  throughout  the  preproduc¬ 
tion  and  service  evaluation  test  stages.  Techniques  and  conformance/non- 
conformanco  criteria  are  provided  in  maintainability  specifications  listed  in 
Figure  KM.  MIL-M-23313A(  SHIPS)  is  typical  of  those  imposed  throughout 
system  development  and  production  programs. 

10.2.11  Scheduled  Maintenance  Considerations 

This  section  has  appropriately  emphasized  the  unscheduled  aspects  of  main¬ 
tenance.  Since  all  maintenance  requirements  must  be  considered  in  the 
Maintainability  Plan,  the  Project  Engineer  is  enjoined  to  include  in  his  con¬ 
siderations,  scheduled  maintenance  aspects  such  as: 

(1)  Cycling  or  turn-around  time  requirements. 

(2)  Provisions  for  concurrent  servicing  of  the  various  subsystems. 

(3)  System  reaction  time  requirements. 

(4)  Troubleshooting  and  fault  diagnostic  methods  desired. 

(3)  The  Systran  maintenance  concept  and  what  it  should  include  (levels 
of  maintenance  and  associated  maintenance  tasks  and  functions) . 

(6)  Periodic  (scheduled)  maintenance  requirements,  including  calendar 
time  or  operational  limitations  governing  inspection  and  rework  of 
the  system. 

(7)  Maintenance  manhour  requirements  or  objectives  per  operating  hour, 
per  flight  hour,  or  other  measure  of  time  or  events. 

(8)  Maintenance  and  operating  factors  for  personnel  requirements 
determinations 

(9)  The  required  or  desired  degree  of  system  readiness  (availability) . 


( 10)  Times  required  for  fault  identification,  isolation,  correction  and  repair 
verification. 

(11)  Maintainability  verification  schedules  and  methods  used  during 
deve'opment  effort. 

(12)  Types  of  missions,  mission  duration  and  frequency,  or  modes  of  op¬ 
eration,  duration  and  frequency. 

10X12  System  Maintainability  Demonstration 

The  validity  of  all  maintainability  assumptions,  predictions,  and  analysis 
techniques  for  developmental  equipment  is  measured  during  the  planned  tests 
and  evaluations  of  SECTION  12.  Data  devised  from  the  system  maintainability 
and  reliability  demonstrations  are  used  to  determine  the  overall  system  avail¬ 
ability  as  described  in  Section  10.1.15. 
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TDP  Check  List 


SECTION  10 

Reliability  and  Maintainability  Plan 


1.  Is  the  TDP  in  response  to  an  ADO? 

2.  If  “yes”,  does  the  TDP  impose  some  requirement  for  reliability  assurance 
during  research? 

3.  If  the  TDP  is  in  response  to  an  SOR,  has  a  detailed  reliability  plan  been 
described? 

4.  Has  the  question  of  reliability  prediction  vs.  reliability  demonstration 
been  considered? 

5.  Have  reliability  goals  beon  established  for  each  mode  of  system  operation 
using  the  SOR  goals  as  a  basis  ? 

6.  Have  reliability  objectives  been  established  for  each  sub-system  of  the  de¬ 
velopment  and  are  these  objectives  quantitatively  defined  in  terms  of 
MTBF? 

7.  Has  a  specific  reliability  prediction  and  evaluation  technique  been  selected 
from  those  available  as  illustrated  in  Figure  10-4  ? 

8.  Has  the  type  of  reliability  program  selected  by  the  Project  Managev  bean 
j  ust  ified  in  the  TDP  ? 

0.  Has  the  intended  operational  environment  been  considered  when  selecting 
types  of  reliability  demonstration  tests? 

10.  Has  a  complete  pirn  been  described  covering  tho  definition,  design,  predic¬ 
tion,  monitoring  and  evaluation  of  reliability  performance? 

11.  Has  a  thorough  cost/effectiveness  analysis  been  performed  using  the  SOR 
availability  goals  as  a  basis? 

12.  Have  quantitative  maintainability  requirements  been  stilted  ? 

13.  Have  maintainability  objectives  for  each  stage  of  system  development  been 
stated? 
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been  assigned? 

15.  Does  the  maintainability  plan  establish  a  schedule  whereby  all  maintain¬ 
ability  efforts  are  reviewed  and  evaluated  by  the  responsible  activity? 

16.  Is  the  maintainability  plan  flexible  enough  to  allow  for  modifications  and 
improvements  based  on  updated  information  ? 

17.  Will  implementation  of  the  maintainability  plan  assure  early  prediction 
and  ultimate  formulation  of  a  realistic  and  workable  maintenance  program 
which  is  in  accordance  with  stipulations  of  the  SOR? 

18.  Have  human  factors  considerations  beon  made  integral  to  the  design  for 
maintainability? 
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